VCs

Verifiable Credentials

Credentials are a regular part of our lives. For example, university degrees, passports, and certifications are all examples of credentials that assert some claim about us.

Based on W3C’s Verifiable Credentials Data Model specs, Terminal 3 provides a set of REST APIs and SDKs for the issuance and verification of digital credentials that are cryptographically secure, privacy-preserving, and machine-verifiable.

Claims

A claim is a statement about a subject. A subject is a thing (typically a person) about which claims can be made.

Basic structure of a claim:

A claim expressing that Terry is an alumni of “OC University”:

Multiple claims can be combined to express a graph of information:

Verifiable Credentials (VC)

A credential is a set of one or more claims made by an issuer. A verifiable credential (VC) is a tamper-evident credential and metadata that cryptographically proves who issued it.

“Verifiable” means a credential can be verified by a verifier. It only implies that an issuer signed the VC; it does not imply the truthfulness of claims.

A VC typically includes credential metadata, claim(s), and proof(s).

Specifically, a VC is a hash presentation in either JSON or JSON-LD format. Here is an example of a VC in JSON-LD:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "id": "https://app.terminal3.io/credentials/58473",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "did:key:terminal3",
  "issuanceDate": "2023-01-01T00:00:00Z",
  "credentialSubject": {
		"id": "did:ethr:0xebfeb1f712ebc6f1c276e12ec21",
	    "degree": {
	      "type": "BachelorDegree",
	      "name": "Bachelor of Science and Arts"
	    }
	},
  "proof": { ... }
}

Notes:

• DIDs are used to represent credential subjects
• Proofs establishing that the issuer generated the credential are required for a VC/VP to be verifiable
• To maximize data privacy and security, VCs are typically stored off-chain

Verifiable Presentations (VP)

A VP expresses data derived from one or more VCs, issued by one or more issuers, that is shared with a specific verifier. It is a tamper-evident presentation encoded in such a way that authorship of the data is cryptographically verifiable.

VPs consist of presentation metadata, VC(s), and proof(s).

We also leverage zero-knowledge (ZK) proofs to enable selective disclosure in VPs.

Triangle of Trust

There are three primary roles — known as the Triangle of Trust — that make up a VC ecosystem: issuers, holders, and verifiers.

Issuer

• Asserts claims about one or more subjects, and creates VCs from these claims
• Examples: enterprises, organizations, and governments

Holder (Subject)

• The entity (typically a user) about whom a claim is issued
• Acquires and possesses one or more VCs, and consents to when, and with whom, they are shared
• May bundle VCs to generate VPs
• Holders may either self-custody VCs themselves, or store VCs in Terminal 3’s decentralized storage
• Examples: consumers and end users

Verifier

• Receives one or more VCs, usually inside a VP, for processing and verification
• Checks that VCs were issued by a legitimate issuer
  • This is done via on-chain DID Resolution; the signature and signing keys in the VC must match the issuer
  • This implies that the Issuer and Verifier do not need to have a direct relationship with each other
• Checks that VCs have not been tampered with, expired, nor been revoked
• Examples: banks, employers, and applications

Verifiable Data Registry

• A system that mediates the creation and verification of identifiers, keys, and other relevant data, such as VC schemas, revocation registries, issuer public keys, etc. which might be required to use VCs.
• Example: blockchains and distributed ledgers.

VC Lifecycle

The lifecycle of a VC (and VP) can be simplified into the following journey:

1. Register Issuer DIDs

   Issuers publish their public keys in an on-chain DID Registry, managed by Terminal 3.
   A DID is used to hold the Issuer’s public key

2. An Issuer creates and signs a VC

   Create a VC and digitally sign it with their private cryptographic key

3. The Issuer transfers the VC to Terminal 3 for storage

   Encrypt the VC - Store the encrypted VC in an off-chain Credential Repository, managed by Terminal 3

4. The Verifier verifies the credential from the Holder

   Request the VC from Holder - Extract DID from the VC - Extract the Issuer’s public key
   Use the Issuer’s public key to verify:
   1. The Issuer has the authority to issue the VC, via the DID Registry
   2. The VC is still valid (not expired nor revoked, via the Revocation Registry)

Can VCs be revoked or deleted?

• Issuers can revoke a VC, by posting to an on-chain Revocation Registry via our SDK
• Holders can delete a VC