Verifiable Credential (VC)

The credential's contents are cryptographically signed by the issuer, making any post-issuance modification immediately detectable. A verifier can mathematically confirm that the data has not been altered since issuance.

• Digital Signature: The issuer signs a hash of the credential payload using their private key
• Hash Chain Verification: Any alteration to a single field invalidates the entire signature
• Non-Repudiation: The issuer cannot deny having issued a validly signed credential

Example: A university digitally signs a diploma VC. If a graduate modifies their GPA, the signature verification fails, and the credential is rejected by any verifier.

Verifiers can authenticate credentials without contacting the original issuer. By resolving the issuer's Decentralized Identifier (DID) and retrieving public keys from a Verifiable Data Registry, verification becomes asynchronous and independent.

• Offline Verification: Credentials can be verified without real-time issuer connectivity
• DID Resolution: Public keys are discovered via the issuer's DID Document
• Registry Agnosticism: Works with distributed ledgers, decentralized databases, or DNS-based registries

Example: A border control officer verifies a traveler's digital passport VC by resolving the issuing government's DID on a public ledger, without needing a live connection to the passport office.

Holders can reveal only the specific claims required for a transaction, rather than exposing the entire credential. This minimizes data exposure and enhances privacy.

• Atomic Claim Revelation: Individual attributes can be disclosed independently
• Predicate Proofs: Prove statements like 'age > 21' without revealing exact birthdate
• Zero-Knowledge Proof Integration: BBS+ and AnonCreds enable cryptographic selective disclosure

Example: When purchasing age-restricted goods, a holder presents a proof derived from their government ID VC that confirms 'age >= 18' without revealing their name, address, or exact date of birth.

A VC is cryptographically bound to its legitimate holder, preventing impersonation and credential theft. The binding mechanism ensures that only the intended subject can present the credential.

• Subject DID Embedding: The credential contains the holder's DID in the credentialSubject.id field
• Possession Proof: The holder proves control of the private key associated with their DID during presentation
• Biometric Binding: Optional hardware-backed binding via FIDO2 or Secure Enclave attestation

Example: A professional license VC contains the licensee's DID. When presenting the license, the holder signs a challenge with their DID's private key, proving they are the legitimate subject of the credential.

Issuers can revoke credentials without needing to access or modify the credential itself. Revocation status is checked against a cryptographically secure Revocation Registry during verification.

• Bitstring Status Lists: W3C BitstringStatusList enables efficient, privacy-preserving revocation
• Cryptographic Accumulators: Allow revocation without revealing which credential was revoked
• Time-Bound Validity: Credentials include validFrom and validUntil timestamps for automatic expiry

Example: An employer revokes an employee's access badge VC. The revocation entry is published to a bitstring list. Verifiers check the list during presentation and reject the credential without learning why or when it was revoked.

VCs use JSON-LD and linked data schemas to ensure that claims are semantically understood across different systems and domains. This enables automated processing without human interpretation.

• W3C Data Model: Standardized JSON-LD structure with @context for namespace resolution
• Schema.org Integration: Credential types can reference well-known vocabulary definitions
• Credential Schemas: Define the structure and required fields for specific credential types

Example: A supply chain VC asserting 'shipment temperature < -18°C' uses a shared schema so that customs systems, logistics platforms, and auditors all interpret the claim identically, regardless of vendor.

A globally unique persistent identifier that does not require a centralized registration authority. DIDs are the foundational layer for VC architecture, enabling subjects to be identified without relying on a single certificate authority. Key properties:

• Resolved to a DID Document containing public keys and service endpoints
• Typically formatted as did:method:unique-id
• Enables cryptographic authentication without an intermediary

A signed aggregation of one or more VCs assembled by a holder to share specific claims with a verifier. The presentation proves control of the underlying credentials without necessarily revealing the raw data. Core functions:

• Combines multiple credentials into a single proof envelope
• Supports selective disclosure to minimize data leakage
• Binds the presentation to a specific verifier to prevent replay attacks

A cryptographically secure data structure that records the revocation status of VCs without exposing the underlying credential data. Common implementations include Bitstring Status List v1.0 and cryptographic accumulators. Operational mechanics:

• Issuers toggle bits to revoke without contacting the holder
• Verifiers check the registry during presentation verification
• Maintains privacy by not revealing which credential was revoked to unauthorized parties