> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminal3.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Smart 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](https://www.w3.org/TR/vc-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:**
```mermaid theme={null}
flowchart LR
subject([Subject])-- Property -->value[value]
```
**A claim expressing that Terry is an alumni of "OC University”:**
```mermaid theme={null}
flowchart LR
student([Terry])-- alumniOf -->university[OC University]
```
**Multiple claims can be combined to express a graph of information:**
```mermaid theme={null}
flowchart LR
student([Terry])-- alumniOf -->university[OC University]
student-- knows -->professor([Gary])-- jobTitle -->job[Professor]
```
# 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](https://www.json.org/json-en.html) or [JSON-LD](https://json-ld.org/) format. Here is an example of a VC in JSON-LD:
```json theme={null}
{
"@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](/documentation/preliminaries/web-standards/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*.
```mermaid theme={null}
flowchart TB
subgraph T[ ]
direction LR
issuer[Issuer]-- issue VCs -->holder[Holder]-- present VP -->verifier[Verifier]
end
subgraph DR[ ]
registry[Verifiable Data Registry]
end
T-- use identifiers and schemas -->DR
```
### 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:
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
Create a VC and digitally sign it with their private cryptographic key
Encrypt the VC - Store the encrypted VC in an off-chain Credential
Repository, managed by Terminal 3
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