Verification conflicts

Verification Conflict is a relatively recent feature of Decidim that is intended to solve problems with the verification or authorization of users.

Verification is the functionality that allows registered users to validate their identity; the most common forms are via email or personal data (DNI, date of birth and sometimes postal code), and for these two methods there are several modules that can be used.

[more information about the verification in Decidm]

A verification conflict occurs when a user tries to enter their data, which must be correct and valid (found in the census), but the system fails and the user sees a message indicating that their data is already being used.

This should not involve identity theft. As administrators, what we have to do, if this happens (we will also have received a notification, of course), is to access the Back Office > Participants > Verification Conflicts.

There we find all the verification conflicts of this kind that have occurred on our platform.

If it does not appear in this section and the participant has the error message, we must check that:

1) he or she has set their data correctly (for example, using the dd/mm/yyyy format on the date of birth),

2) or confirm that she is a user who is in the census.

If these two points are correct, we are faced with a "Verification Conflict".

What we see is that the User (person who is trying to be verified) is trying to use the Managed user data (user who at some previous time used the same data to authenticate).

In other words, the verification conflict occurs because a user is trying to verify theirself with data that is linked to another account.

Why is that?

This type of conflict can occur in two different scenarios:

• Users who create a new account.

Sometimes it happens that a user had an old account with which she had used their verification data to validate their identity, and no longer remembers this account or has no access to it. For this reason, a new user account is created and when he or she try to verify with their new account, ir occurs the conflict. 

Decidim is very carefully about verification data; an almost unbreakable link is created between a user account and verification data. Even if the old account is removed, the system knows that the verification data has already been used before and does not allow reuse.

To resolve the verification conflict that occurred in this case, Decidim has developed the Transfer functionality.

• Impersonation.

One can have the situation of a user who, at one time, had participated through impersonation without having a previously created account. Remember that when we impersonate, we must use the verification data (this is why only people who are on the census can be impersonated).

[more information about impersonation]

Impersonation does not create a user as such, but it does bind the verification data to a semi-account, so it cannot be used again. This explains why we cannot impersonate two different people with the same data, or why the same user, who has now created an account on the platform, when trying to use his or her data, makes an error.

In this context, too, there is a verification conflict, and we can also solve this with the Transfer.

The Transfer

As we said, Transfer is one of the solutions Decidim offers to resolve a verification conflict.

The transfer serves to merge the two users who have come into conflict, so that the activity and verification data of one (the old account or impersonation) are available in the user's account you want to use (the new account created).

To do this, when we got to the Transfer section, we must specify, in the "Email" field, the email of the account we want to keep. Normally, this mail is what we see in the User column (the new account), but we recommend contacting the user first and confirming it.

Do not forget to indicate the reason for the action and click Transfer.

• Here is an example:

Ariadna’s account was created in 2019 (ariadna.va+old@coditramuntana.com) and she verified herself to participate and vote in a participatory budget. She hasn't participated in the platform until now and no longer remembers that she had an account, so she created a new one with a new email (ariadna.va+new@coditramuntana.com).

Old user account activity and new account creation:

When she tries to vote, the error message comes out saying that her data is being used.

Once Ariadna has complained that she cannot vote, we as administrators have confirmed that she is on the census and we see that there is a new verification conflict with that user account, we can do the transfer:

1. Click on the transfere button.
2. In the Email field, we specify the email that is shown in the User column (which is the new account).
   In this case, let's put the mail "ariadna.va+new”coditramuntana.com"
3. Click Transfer.

Once this transfarence has been performed, we can see that Ariadna has now only one account: old name and alias, but the new email. This is because we have merged the two accounts, so with the new account access data, the user retains the activity and verification information of the old account.

Now Ariadna can vote!

With verification conflicts coming from an Impersonation, transfarence is simpler because there is no email from an old account. Only the email from the User field should be indicated.

Other solutions: Revocation

One option to avoid verification conflicts when we start a new participatory process is to revoke verifications.

As has been said, once an authorization or verification data has been linked to a user's account, this link is almost impossible to remove. The only way the system allows is through revocation. This action removes existing verifications, so the data can be reused.

There are three ways to perform revocations:

1. Revoke all verifications on our platform. Revoke all.
2. Revoke all verifications that were previously performed to a specific date. For example, we can remove all them made before the start date of our participatory process, so newly created users who have already been verified do not lose their status, but we "clean" old verfiications that may either generate verification conflicts, or may be from users who are no longer in the census. Revoke before date.
3. Revoke only the verification data used for Impersonations that we have previously performed to a date. In this way, we avoid conflicts caused by impersonations. Impersonated only.