In this journey of understanding verifiable credentials and what goes on the ledger while building a decentralized identity solution, we had a glimpse of the following – 

• DID
• Verifiable schema
• Verifiable credentials and
• What happens when VC is issued

An important aspect in this process is where to keep the public information. As blockchain brings the power of immutability, it is used as a single source of truth.

In W3C terms, a ledger is referred to as Verifiable Data Registry. It can be trusted databases, decentralized databases, government ID databases, and distributed ledgers. An ecosystem can utilize more than one type of verifiable data registry as well.

Hyperledger Indy is the first distributed ledger purpose-built for decentralized ID. Ledger will mediate the creation and verification of identifiers, keys, and other relevant data. All this information might be required to use verifiable credentials.

What goes on ledger

Before Issuance

Public DID, keys and Endpoints

Public decentralized identifier (DID) is an integral part of the identity ledger. DID which are used for verification should be stored on the ledger to be publicly available, like that of the Issuers.

Each DID has its own DID Document (DIDDoc) or DID descriptor object (DDO) also stored on the ledger. It contains metadata needed to prove ownership and control of the DID.

It also contains information about resource endpoints to help peers interact with each other. Endpoint is the location of the identity owner such as URL or IP address. It enables peer-to-peer communication between the parties without intermediaries and secured by DIDs.

Verifiable credential Schema

We talk through schema in part 1 of the blog series. ID of the Credential schema along with the metadata (attributes, owner identifier, type) information is also recorded on the ledger. This encourages reusing the credential format and fosters uniformity.

Credential schema provides verifiers enough information to determine if the provided data conforms to the provided schema.

In Indy, Schema and Claim Definitions are two artefacts created for definition and regulating the Verifiable Credential Schema.

Creation of revocable schema during Issuance, and after Revocation

Revocation registries

Revocation is a vital part of any identity ecosystem. The question is how to revoke issued credentials and manage the revocation information?

No private data, claims or VC information is stored on the ledger. Revocation files are always an accessible list outside the ledger that contains information about the claim and it’s revocation status.

Each Issuer must publish a revocation registry to the ledger referencing a verifiable schema (claim definition in Indy) and contains an accumulator used for verifying the status of membership. An accumulator is a complex combination containing information about the credentials. Its value changes when a credential is added to or removed from the list.

For example, if the driver’s license department has revoked 4 licenses during the working time, they might publish a ledger transaction to update the revocation status(accumulator value) when they close their doors. This will update the ledger and anyone verification of the revoked driver’s license will fail.

No Private Information should be stored

Best practices suggest not to store any private information which includes proof transactions and claim transactions on the ledger. But, there may be business cases where parties agree to store transactional data on the ledger. For example, a company may want to publish registration information, address, list of founders/ directors etc. As a Network Owner and the ecosystem development entity you have to address such scenarios to store the information securely on the ledger.

With this, we hope it provides a better understanding of Decentralized Identifier (DID), key components that makes a verifiable credential, information can go and should go on the ledger and finally breakdown of the VC Issuance.

Watch out the next blog to understand how all these things will come together during the verification process.

Write to us at info@blockster.global or follow up on Linkedin if you have a query or to get more information on the subject.