In my last article, I described the idea of Self Sovereign Digital Identity, and how it will provide both security and privacy that will be in the control of the subject (user, entity) itself. In this article, I will demonstrate how it works. I will use a simple, but closer to real life scenario to show various participants, and use of self sovereign digital identities for obtaining a Real ID¹.
The participants in my example scenario are
- Alice, who is interested in getting a Real ID.
- Social Security Administrator (SSA), who issues Social Security Card.
- Department of State (DoS), who issues Passport.
- A Bank, who issues Statements for the account that Alice has with them.
- Department of Public Safety (DPS) who will issue Real ID.
In our example, Alice requests for a Real ID from DPS. Let’s suppose that DPS needs to verify the following information about Alice before issuing a Real ID to her.
- 16 years or older
- Citizenship
- Name and Address submitted by Alice
DPS suggests that Alice can use the following form of credentials to meet the above verification requirements.
- Social Security Card for Name verification
- Passport for Name, Age, and Citizenship verification
- Bank statement for Address verification
Alice needs to establish digital relationship with SSA, DoS, and Bank so that she can receive the suggested credentials from them. Let’s suppose that SSA, DoS, and Bank had created public DIDs (Decentralised Identifiers) and stored those in some publicly accessible VDRs (Verifiable Data Registry).
The figure 2 below demonstrates the creation of public DIDs.
Few things to note in the above diagram
- Alice and DPS do not have public DIDs - just to demonstrate that not all participants are required to have public DIDs.
- The VDR represents the network of all VDRs. This is to demonstrate that the public DIDs do not need to be created and stored in the same VDR.
- The issuers of credentials such as SSA, DoS, and Bank also store the definition of credentials in the VDR. The consumer of the credentials use the definitions to interpret the credential. These credentials are called as Verifiable Credentials (VCs).
- The DIDs such as did:gov:ssa, did:gov:dos, and did:vdrA:bank follow a specific naming convention. I will go over this convention in one of my future articles. For the purpose of this article, these are just made up DIDs just to demonstrate the concept.
The figure 3 below demonstrates the process that Alice follows to establish a Peer DID relationship with the Bank, and obtain Statement as a VC. Though not shown in the diagram, similar steps Alice follows to obtain SS card, and Passport from SSA and DoS.
Create Link Secret: In this article, I will describe what’s it, not how it’s used. The link secret is a large random string that Alice generates. It’s used to prove that the VC was issued to the subject, in this case Alice, without having Alice to reveal her peer DID, which is supposed to be private, to the verifier of the VC. Alice never reveals the link secret to the verifier, rather provides proof that she knows about it — the concept of Zero Knowledge Proof (ZKP). To make it distinct for each issuer, she adds a nonce to the secret link, and wraps it in a cryptographic commitment. This cryptographic commitment of link secret and nonce is termed as Blinded Identifier.
Create Peer DID Relationship: Alice generates a unique public & private key pair that will be used to establish a relationship with the Bank. She creates a DID, say did:peer:AliceBank, and associates a DID Document with this DID. The DID Document will contain the public key that Alice had generated for this relationship.
Alice finds the public DID of the bank (did:vdrA:Bank) from wherever the Bank has published it — may be Bank portal, or an API etc. Alice finds the corresponding DID Document from the VDR, and then retrieves the Bank’s public key from the document.
Alice signs her DID and DID Document using her private key. She encrypts all of these using Bank’s public key, and then shares the encrypted DID and DID Document with the Bank.
Bank is the only entity that can decrypt the message using its private key. It will retrieve Alice’s DID and DID Document from the message. It will obtain Alice’s public key from the DID Document. It will use Alice’s public key to verify the signature and hence the authenticity of the message.
Prior to sharing DID and DID Document, Alice may use challenge response to authenticate the bank — it encrypts a challenge response message using Bank’s public key, and then Bank decrypts the message using its private key. The Bank then sends back the response that’s signed using its private key. Alice verifies the signature using Bank’s public key, and the content of the message. This assures Alice the authenticity of the Bank.
The peer DID relationship is a mutually authenticated and uniquely identifiable relationship between two parties.
Issue Verifiable Credential: Alice creates a Blinded Identifier, SB, and requests Bank to issue her a recent Statement that’s bound to SB. The Bank issues the requested Statement in the form of a VC. The exchange of all these communications between Alice and Bank is performed using DIDComm Messaging Protocol. This protocol assures the confidentiality, integrity, and authenticity of the communication. I will go over this protocol in one of my future articles.
The VCs that Alice receives for SS, and Passport will be bound to blinded identifiers SS and SU respectively.
The figure 4 below shows the final step in which Alice provides the required information to verify her eligibility and receive a Real ID from DPS.
Alice first establishes a peer DID relationship with DPS. She confirms to DPS that she has the following VCs from different issuers to establish her eligibility for a Real ID.
- SS from did:gov:ssa
- Passport from did:gov:dos
- Statement from did:vdrA:bank
The DIDs mentioned above are all public DIDs. The second part of these DIDs tell DPS where it can get required information to verify the VCs. It retrieves DID Document and definition for SS from VDR “gov”, for Passport from VDR “gov”, and for Statement from VDR “vdrA”. It retrieves the public keys of these issuers from their respective DID Documents. It uses the public key to validate the signature and hence the authenticity of the VCs. It uses the definition of VCs to understand what information and how to use the information from the VCs.
Let’s suppose that DPS relies on SS to verify the name that Alice has provided. It asks Alice to retrieve and provide the following information from the VC: name, issuer signature, and the blinded ID that the VC is bound to. Few things to note here
- Alice is sharing only “name” from SS, not the number
- Alice is not sharing her peer DID that she had established with SSA. That’s private and remains unique and known between her and SSA.
- Alice is just sharing the blind ID that the VC is bound to so that DPS is able to verify that the VC was issued to her. Sharing the blind ID doesn’t reveal the link secret, it just proves that she has the knowledge of it.
- DPS uses the issuer public key to validate the signature on the VC to establish the authenticity of the VC.
Similarly DPS will request Alice to use Passport, and provide the following information only, nothing else.
- Yes or no to the question if she is older than 16. She doesn’t share the date of birth from the Passport.
- Yes or no to the question if she is a valid citizen. She doesn’t share issue or expiry date, issuing authority etc.
- Name that DPS verifies against the name retrieved from SS.
DPS will request Alice to use Statement, and provide address information only and nothing else.
The idea of presenting only need to know information from multiple VCs, and not the entire VCs is termed as Verifiable Presentation. I will go over this concept in detail in one of my future articles.
Upon validating the eligibility, DPS issues Real ID to Alice. This Real ID can be in the form of a VC or physical one.
I covered the idea of Self Sovereign Digital Identity, and how it will provide both security and privacy that will be in the control of the subject (user, entity) itself in my first article. In this article, I showed how all it works. I will dive deep into concepts that make it all work in my future articles.
- Decentralised Identifiers (DIDs)
- DID Document
- Verifiable Credentials (VCs)
- Verifiable Presentations
- DIDComm Messaging Protocol
References:
