How to Guarantee a Seed Document is Associated with Single Identity


#1

Some applications, such as voting or membership clubs with shares, etc., need to ensure that there is a 1:1 mapping of an identity-owner and a real-life person (or their proxy) participating in an activity. It would not be acceptable if a person could create 10 identities and vote 10 times.

I am new here, and have been studying Sovrin – loving what I am seeing. However, from what I have learned so far (apologies if misunderstand), I do not see a simple way to enforce this.

This would require trust anchors who require that their stamp of approval or documents are only associated with a single identity owner, to keep their own centralized data stores correlating each DID with seed documents, such as a social security number. They would first need permission to view and store the seed information for an identity holder. The issuer would look in their database for any other DID’s already using this and take appropriate action. All more liability than desired.

Multiple that by potentially hundreds of trust anchors doing the same thing, or using a commercial service with its larger attack vector, and it gets to be security nightmare, not to mention less performant.

It would be fantastic if the responsibility for this could be shifted down a level into the identity management layer to guarantee that for claims issued by certain types of trust anchors with unique document identifiers, that a specific claim can only ever be associated with a single identity holder.

Then a predicate check is not even needed. If an identity holder who has a claim of this nature, it is already guaranteed that there are no duplicates.

It is not just issuers of claims based on seed documents that would benefit from this, but any trust anchor who needs to guarantee that no members within their set of claims are duplicated via criteria established by seed document uniqueness – extending the web of trust. So, this could be for voting in a club or virtual nation, or sharing of proceeds.

My idea is to add an additional ledger into sovrin specifically for anchoring what I am nicknaming UDI’s (Unique Document Identifiers) and their associated documents. This separation into its own ledger would allow the whole process to be optimized and fast.

A UDI, looks like udi:issuer:document-id-hash

And its document like this:

Udi:socsec:hash {

owner: did:sovrin: 12345678abcdef01

issuer: did:socsec: 12345678abcdef02

status: r (revocation), a (active), (others possible)

timestamp: (optional) (timestamp op initiated)

}

If issuer is replaced with word private, and the issuer is combined with the document id into the hash, then looks like this.

This requires some more round trips for an issuer to revoke, however the type of document can no longer be correlated with an identity holder (this correlation might be a good thing, in any case it can be permissioned).

Udi:private:hash {

owner: did:sovrin: 12345678abcdef01

issuer: challenge

status: r (revocation), a (active), (others possible)

timestamp: (optional) (timestamp op initiated)

}

Creation of the UDI and its document is handled by sovrin. Have worked out a few more details not shown here. In all cases by indexing the ledger, it is possible to correlate documents which have moved from one identity owner to another. This might be a good thing? It would also assume that the system is not abused with claims that are not related to identity uniqueness.

Please let me know your thoughts, including if missing the boat somewhere, or if there is a better way of doing this, or if above sounds good: what are steps to help make it so.

Thanks,

Michael Khalsa