What Links Identity and VCs Together Across Applications?
Protecting user data from identity fraud has become challenging for businesses in this dynamic environment shaped by privacy and security concerns.
A possible solution to these problems is Self-Sovereign Identity (SSI), a revolutionary identity framework that empowers users to determine where their data is stored, how it is used, and with whom it is shared. A popular way to implement SSI is through Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs), two W3C standards that create a common layer for user authentication and verification.
A DID is a unique identifier built on the Distributed Ledger Technology (DLT) and it is linked to a DID document, that in turn, contains information about an entity. A VC, on the other hand, is a cryptographically verifiable and machine-readable credential of an entity such as the date of birth, government ID, vaccination records, employment details, etc.
Now comes the big question — how are VCs tied to an entity’s identity in any application?
VC Issuance and Verification
To understand the relationship between VCs and DIDs, let’s talk briefly about the issuance and verification process.
There are three parties involved in VC issuance and they are:
- Issuer — the entity issuing the VC. For example, the Motor Vehicle department issuing a driver license
- Holder — the owner of the VC. For example, the individual who owns the license
- Verifier — the entity verifying the authenticity of the VC. For example, a police authority who wants to issue a speeding ticket.
Together, these three entities form what’s called a trust triangle, and this is a key requirement for implementing SSI. The trust aspect among these entities is handled by public-key cryptography, a pair of private and public keys that always work together.
The process begins when an issuer creates a VC about the holder and digitally signs it with its private key. The holder, on receiving this VC, uses the issuer’s public key to decrypt the information, and store it in his or her digital wallet.
When the holder wants to share this VC with a verifier, he or she creates a verifiable presentation that contains one or more VCs such as date of birth, driver’s license, address, etc, and signs it with his or her private key.
The verifier decrypts the VC with the holder’s public key to access the information and authenticates that it came from the right source by using the issuer’s public key.
Role of Decentralized Identifiers
A DID is a unique identifier that is linked to a DID document through a DID method.
Essentially, the DID method resolves the DID and helps to locate the associated DID document. You can imagine it to be something similar to what a URL would do to locate the web server containing information.
This DID method is implementation-specific and varies according to the network or distributed ledger where it is implemented. The DID document, on the other hand, contains information about the entities involved in JSON format.
Link Between VCs and DIDs
To answer the question of how VCs are linked to identity across applications, we must understand how VCs are linked to DIDs.
Earlier, we said that the DID document contains information about the entities, and this includes information about their public keys and the cryptographic algorithm used. This information is then used for verifying the identity of the entities.
Here’s a sample DID document.
italic text In other words, DIDs contain information that can verify the authenticity of a VC.
Workflow of DIDs and VCs
To further elaborate, let’s look at how VCs and DIDs come together from an implementation standpoint.
Step 1 — Creating a DID
The first step is to create a DID using a specific DID method. The issuer can decide to create a new DID for each VC or use the same DID for all VCs issued to a holder.
Step 2 — Adding Information to the DID Document
The cryptographic keys of the DID are updated in the DID document.
Next, the issuer has to collect and/or verify the identity of the holder as required. The exact process of this step would depend on the type of credential. For example, VCs for proving that the holder is more than 21 years requires less stringent verification than issuing a driver’s license.
The issuer takes this responsibility of verification and accordingly issues a VC to the holder.
Step 3 — Signing the VC
The VC issued by the issuer contains the DID of both the issuer and the holder and it is digitally signed with the issuer’s DID. After the signing process, the issuer sends the VC to the holder
Step 4 — Revoking a VC
At a later point, the issuer can choose to revoke the VCs issued, especially if they are no longer related to the holder. While many implementations don’t support VC Revocation, Affinidi’s tech stack has simple methods to revoke VCs.
Step 5 — Verifying the VC
The holder creates a verifiable presentation consisting of one or more VCs and shares it with a verifier.
The verifier has to resolve the DID documents from the DID of the issuer and the holder present in the VC. Using the DID method, the verifier can check if the VCs sent by the holder are authentic.
The verifier also uses the DID methods to check for revocation of the VCs.
If found authentic, the verifier can offer its services to the holder.
From the above workflow, it’s clear that VCs are bound with DID, which in turn, reveal the identity of an entity. Since these are interoperable and are not tied to a centralized authority, VCs have many use-cases across different spheres.
Thus, this is how VCs and identity are linked together across applications.
The information materials contained in this article are for general information and educational purposes only. It is not intended to constitute legal or other professional advice.