Document number verifications in initiatives signature

[entantoencuanto]

This issue is part of the EPIC: Signature process of an initiative #4644

Add these steps to vote creation (sign):

• Check that provided document number matches with the hash stored in the authorization process.
• After that check that the document number hasn't been already used to sign the initiative, a checksum with Document number and initiative should be enough.

[entantoencuanto]

Hi, @decidim/product!

I have a doubt with this. If the organization doesn't have enabled the census verification, but the personal data user extra fields collection is enabled for the initiative, do we have a mechanism to match provided document with a hash in the database other than the census verification?

In case not, we should allow users signatures?

[arnaumonty]

Hi @entantoencuanto

I have a doubt with this. If the organization doesn't have enabled the census verification, but the personal data user extra fields collection is enabled for the initiative, do we have a mechanism to match provided a document with a hash in the database other than the census verification?

I'd said no but maybe @andreslucena or @oriolgual can confirm it. Maybe it should work with ID verification too but I'm not sure if we keep the hash in the same way as census verification.

In case not, we should allow users signatures?

In Epic #4644 is defined, in "As an administrator I want to":

• For each type of initiative I have to be able to define what type of verification (authorization) is needed to be able to sign.

• For each type of initiative the extra fields to fill in when the user sign, have to be enabled or disabled from the administration panel.

Following these principles, and in case that we have enabled the extra fields step but no verification with a census, I wouldn't check the ID hash.

[entantoencuanto]

Additionally, the metadata of the authorization associated with the verification should be consistent with the other personal data provided by the user and information about the initiative scope. In this way the authorization handler would detect if the user belongs to the correct scope. For this, the authorization handler should be able to generate a metadata hash containing information about the scope and the postal code

[arnaumonty]

@entantoencuanto It seems a good solution, but we should take into account if the user is always providing this information or not and what happens if not, or maybe provides just one of two items. It would be possible to generate a hash for each one? Tomorrow we have a product meeting, we can comment it and we can have a call just to clarify the best option.