SSI space has moved a long way. The concepts of SSI, Decentralized Identity, and verifiable credentials (VC) have been explored by many forward thinkers across the industries.

There is enough material available online to understand the concepts of SSI and the steps involved in VC issuance, verification, and revocation. Still, we find it a bit tricky to consume them as is.

Hence, we thought of creating a series of blogs to make it easy for a SSI developer to dive into the creation, issuance, verification, and revocation of a VC. This article is to explain in a more granular way on what actually happens under the hood when VCs are issued and what makes VCs verifiable.

To make the article comprehensive, let’s have a quick recap of DID and VC. This article is not boxed to a framework or library say Hyperledger Indy and is based on W3C standards for Verifiable Credentials.

DID (Decentralized Identifier)

It is essential that all the entities (Issuer, Verifier, Holder) which are part of the Verifiable Credential ecosystem will have their unique decentralized Identifier or DID.

DID is a globally unique persistent identifier that does not require a centralized registration authority. Because it can be generated by anyone and/or is optionally registered cryptographically onto a verifiable data registry such as a DLT/Blockchain or a traditional database.

Example of a DID:

VC (Verifiable Credential)

Verifiable Credential is a digital credential that comes with Cryptographic power which makes it tamperproof, secure, and verifiable.

Lifecycle of a Verifiable Credential

A verifiable credential goes through four different stages

1. Issuance of a credential
2. Storage of a credential
3. Presentation of a credential
4. Verification of a credential

Verifiable Credential Creation and Issuance:

It is essential that all the entities (Issuer, Verifier, Holder) which are part of the Verifiable Credential ecosystem will have their unique decentralized Identifier or DID.

DID is a globally unique persistent identifier that does not require a centralized registration authority. It can be generated by anyone and/or is optionally registered cryptographically onto a verifiable data registry such as a DLT/Blockchain or a traditional database.

Depiction of credential issuance

Credential Schema

Before issuing a Verifiable Credential Issuer needs to write the credential schema also called a template or JSON schema on the ledger. This credential schema guarantees the structure and by extension the semantics, of the set of claims comprising a Verifiable Credential. A shared Credential Schema allows all parties to reference data in a known way.

There can be four viewpoints for a credential schema:

• Author: An author creates a schema as a blueprint for a verifiable credential, specifying the shape and format of the data.
• Issuer: Issuers use schemas to provide structure and meaning to the data they issue as verifiable credentials.
• Verifier: A verifier requesting data needs to do so with knowledge of the credential schema. Credential Schemas allow a Verifier to ask for data knowing that an issuer has issued in an understood way and that a holder’s wallet can find data matching that requested.
• Holder: Holders, or those to whom a credential is issued, can make sense of the data they own (values) by viewing it against schema keys. When data is requested from them by referencing a Credential Schema, this known structure allows the holder’s wallet to return the data specifically requested by the verifier.

Features of a Schema

1. A schema is versionable
2. A schema is available for any issuer to use and any verifier or another platform member to read
3. A schema always defines the structure of a credential

Follow for example of a JSON Schema as per W3C standard can be found here:

An Issuer can either use the existing Schema or create a new one and Issue credential

Issuance of Verifiable Credential

When an issuer creates a verifiable credential, it contains the following information – 

• Who has issued – DID of the Issuer
• To whom it is issued – User Identifier
• Attributes of the credential – Details of the credential being Issued
• When it is Issued – Date of issuance
• Credential proof with Issuer signature that makes it tamper evident
• Revocation details
  • A user can generate a digital proof out of the credential, digitally sign it and present it as a proof to the verification authority.

So now that you’re familiar with how W3C verifiable credentials (VC) work, watch out for our next blog to get the details of what goes to the ledger in the credential issuance process.

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