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.

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:

​

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