The nuts and bolts of decentralized identity

A tale of three entities - Subjects, Issuers and Verifiers.

In this post, we will focus on understanding the main entities involved in a decentralized identity and verifiable credentials workflow and key components that make the system functional. I assume the reader has sufficient familiarity with the concepts of decentralized identity and verifiable credentials.

Subjects, Issuers and Verifiers are the three key players in a decentralized identity system. Subjects are consumers or users to whom identity claims are issued in the form of verifiable credentials by issuers. Subjects often are also holders of the credentials; though they need not be. For example, when subjects are kids, pets or devices, receiving credentials, the holder is often the parent or owner who is capable to running an identity wallet app on his smart phone and managing identities and credentials for his subjects. Issuers typically are public organizations that handle and verify information from other users, such as universities, government offices, banks and financial institutions. Verifiers are entities that are capable of verifying the identity claims presented by holders on behalf of subjects. The authenticity of the claim is verified by checking the cryptographic signature on the presented credential.

Cryptographic signature verification uses asymmetric cryptography. Each entity in the system possesses a unique pair of cryptographic keys known as the public key and the private key. The private key is secret and is never shared with anybody while the public key is made publicly available for discovery and lookup. If a certain issuer has signed a credential with his private key, everyone else can verify the authenticity of that credential by obtaining a copy of his public key and using it to run a verification algorithm on the signature.

The interesting point to note in a decentralized identity system is that each entity can have multiple roles; for example, issuers can also be verifiers or subjects.

Decentralized Identifiers - All entities in the system are identified with unique identifiers known as Decentralized Identifiers or DIDs in short. Typically, issuers and verifiers are public entities whose DIDs are known publicly and published with the intent of enabling discovery. DIDs of subjects on the other hand are private by default. The identity wallet generates separate DIDs for interactions across entities to explicitly avoid correlations. Private DIDs are shared only as part of an interaction with an issuer or verifier. If a specific interaction requires the user DID to be public, it can be made public as well. Doing so, however, will not expose any other information associated with the other private DIDs.

So the key question here - Where are DIDs published and how do other users discover who they belong to? Enter distributed ledger !

The distributed ledger (DLT) or the blockchain is what powers the decentralized identity system. Think of it as the phone book (picture Yellow Pages !) . Just like how the phone book acts as a directory where businesses are listed, distributed ledgers play a similar role for a decentralized identity system storing publicly listed DIDs and other public information associated with them. Each entity can publish and control their own meta-data listed on the ledger; anytime there is a change, they can update this information instantly. This meta-data is stored in a document, known as the DID Document. It carries all relevant information about the DID Owner and cryptographic material to prove the ownership of the DID. Only the owner of the DID can make any changes to the associated DID Document. This is where the public keys associated with the DID are listed, which are used by everyone to verify credentials. Any entity can query information related to a DID. The DLT will return the DID Document as a response to the DID query.

In addition to DID and DID Documents, the DLT also stores credential definitions and revocation information.

Credential definitions - For credentials to be digitally issued and verified, issuers and verifiers have to agree upon what each credential looks like, what fields are present within the credential and how each field should be interpreted. This standardization of the data fields and their respective data types forms a credential definition that is published on the ledger by issuers. Verifiers refer to credential definitions while interpreting and verifying credentials. Credential definitions can be updated as the requirements evolve. Multiple definitions can be published for the same credentials and differentiated using a version number. Each credential issued has a matching definition and a version number on the ledger.

Revocation Information - Revocation information is also published on the DLT so that others can verify that the credential is still valid and not explicitly revoked. Issuers can publish information in a privacy preserving way on the distributed ledger that allows verifiers to confirm that the credential is valid but does not expose the revocation list explicitly.

The DLT does not store credentials or any private or personally identifying information.

The distributed ledger stores data that is only meant to be publicly accessible and available to everyone. The ledger data is distributed on multiple nodes that belong to one or more institutions that are stake holders in a given identity system or a public ledger utility. Because of the distributed nature of this data, it is resilient to failures and highly available.

Where is private data stored ? Verifiable credentials are stored directly on the user’s device in an encrypted form. Additionally to prevent loss of data due to device theft or loss, as well as portability, they are backed up in an encrypted form to cloud based-storage of user’s choice. The keys that are capable of decrypting this data are in control of the user alone. Therefore a compromised cloud storage account cannot leak the private data. That leads to the natural question, where are the private keys stored ? The private keys are stored in the secure storage of the device in an encrypted form. The keys are derived from a passphrase that the user has to safely stow away once the wallet is activated. The passphrase can be used to generate the private keys to port the identity wallet to a new device.

Want to know more about identity wallets and verifiable credential workflows? Subscribe to stay updated !