Preventing double registration


We are developing a pilot for the use of sovrin in the setting of humanitarian aid in disaster areas. One of the processes we want improve is cooperation between humanitarian organizations with regards to registration and identification of people that need help. So for example:

  • Humanitarian organization named Y would give out claims for people that needs help with the attributes name, age, coordinates of his/her house. They do this by having a physical meeting with these people and checking the passport for example.
  • Humanitarian organization X runs a program in which cash is distributed to people over a certain age living in a certain area and people can sign up digitally. X and Y trust each other and therefore X would accept zero knowledge proofs of claims given out by Y and can therefore help people without knowing their full identity.

This seems like a workable scenario. We are however wondering to what extend we can prevent double registration.

So for example if there is a third humanitarian organization Z also giving out claims following the same schema as Y. Z is also trusted by X and claims from Z can therefore also be used to participate in the the program.

How could we prevent a person from creating a 2 wallets or/ using two phones to both register with Y and Z (or even register twice at Y). And then using both claims stored in different wallets to participate twice with the program of X and therefore receive cash twice.

Is there a method in Sovrin system to prevent double registration or does anyone have a suggestion outside of Sovrin to prevent this?


Hello Ruben,

Double registration can be prevented by using a bio-metric as an “authentication” method combined with an activation code from the HO ( Humanitarian Organisation itself ).

The suggestion is outside Sovrin, and the community might have more input for you.


During the Blockchaingers Hackathon in May in Groningen we faced a similar challenge and went for face-recognition as way to prevent double registrations. preventing de-duplication is hard. Either background checks (basically KYC), but in these scenarios it is impossible. The only good way is biometric-based and that is problematic unless you go deep into privacy protections.

I have some recommendations but we can discuss that offline if you wish.


Hi Ruben, Tey, and Khalid

I am also very interested in this area of establishing uniqueness, both for humanitarian, as well as where strong but different verifiable claims are present (such as would be used for voting and petitions), without each organization having to reinvent their own wheel, or keep their own centralized repositories to look for duplicates.

A claim for uniqueness within a set of identities used by a particular domain.

Khalid - curious why facial with its much higher error rate, rather then iris.
Has anyone tried a combination of bio metrics, perhaps with facial the first layer?

What if each time an issuer using a unique document id issues a claim which is accepted; automatically creates or modifies a document on Sovrin based on that unique document id (on a different ledger perhaps).

The inserted record in the document consist of the
of the DID of the identity holder combined with some random salt and signed by the issuer. Thus it would be uncorrelatable or readable to any other party (as long as the signing key is not exposed).

The next part would require some kind of broker (I know there could be trust issues with that), where the broker takes on one side the resolved DID’s from the issuer, and on the other side the entire set of DID’s registered for the organization looking for duplicates, and returns a pass/fail, or else the duplicated DID’s (since the organization already knows them).

Thoughts, and would really appreciate any insights or help in this area.

(apologies for bold part in reply, was not intentional and unable to remove).


@RubenGeo Sorry this has gone unanswered this long—the past two weeks have been thick with identity conferences including the Internet Identity Workshop so it’s tapped a lot of manpower.

In any case, what you are referring to is broadly known as the “unique person problem” or the “one-person-one-vote” problem, and it’s a ubiquitous problem in Internet identity—precisely because it’s a very hard problem to solve, particularly at scale.

I would not say that Sovrin inherently has a single method to solve it. However it does have a general approach, which you can sum up as “multi-source digital credentials”. In other words, while there is no single solution to one-person-one-credential, many different credential issuers can have their own solutions. For example, a country’s passport office can have a policy that you can have only one passport from that country. Same for a driver’s license. Same for a student account at a university.

So one way to solve the problem is for the humanitarian organization to require the identity owner to present proof of several credentials, each one of which is from an issuer that enforces a “one-person-one-credential” rule. Defeating such an approach requires an attacker to get more than one credential from several different issuers, which makes it much harder (though not impossible) to compromise.

I hope this helps.


How would the organization use this information for correlation? Is the approach to verify the person, and then issue a DID with some kind of internal reference in the metadata? As DIDs themselves do not allow correlation, how is the organization to flag whether or not they’ve seen this person before without being able to reference a single ID? Is the correlation, therefore, limited to a global ID stored on the central server of the organization?


Yes, you are exactly right. Think of it this way: the one-person-one-account problem cannot have a single, global solution without creating a universal correlation database that would be a privacy nightmare.

So each organization (“verifier”) that needs to implement one-person-one-account maintaining their own account database that enforces uniqueness. Each self-sovereign identity owner that signs up will need to present proofs of the credentials required by that verifier to prove uniqueness. But those proofs need to be privacy protected so two verifiers that both maintain one-person-one-account databases cannot correlate with each other.


That is very helpful. Thank you, @Drummond


@Drummond Can the cryptographic accumulator of a credential be used as a unique identifier across multiple DID connections? I’m assuming that the same type of credential is required by the verifier in all DID relationships and, given that the accumulator can change over time, that the window of time is either fairly short, or that the accumulator is unlikely to change often, given the nature of the credential.

So, for example, if voting required a driver’s license be validated, could the voting house internally store the cryptographic accumulator of the license, even with a zero-knowledge-proof, to prevent a separate DID pair from using the same credential for a second shot at the ballot?


Jared, I’m not enough of a ZKP expert to answer definitively, but I’m pretty sure is that it’s not the cryptographic accumulator that will be used across multiple connections. I’m hoping @mikelodder7 can jump on this one.


A value from a credential can be used in an accumulator set and the verifier would have to check that the value is not already there. Since this accumulator can be an add only this is the double spend proof.