Verifiable Credential

The foundational property enabling trust without centralized intermediaries. A digital signature created using the issuer's private key is embedded in the credential. Any verifier with access to the issuer's public key or Decentralized Identifier (DID) can cryptographically validate:

• The credential's integrity (it has not been tampered with)
• The credential's authenticity (it was issued by a specific, trusted entity)
• The credential's non-repudiation (the issuer cannot deny having issued it)

This mechanism relies on Public Key Infrastructure (PKI) or distributed ledger-based key management, often using schemes like BLS Signatures for efficient batch verification.

Verifiable Credentials do not rely on centralized identity providers. Instead, the issuer and subject are identified by Decentralized Identifiers (DIDs)—globally unique, persistent identifiers that require no central registration authority. A DID resolves to a DID Document containing the cryptographic public key material required for verification.

• Eliminates single points of failure and vendor lock-in
• Enables identity portability across different trust ecosystems
• Supports various DID Methods (e.g., did:web, did:key, did:indy) for different infrastructure needs

A critical privacy-preserving property. The credential holder does not need to reveal the entire credential to prove a specific claim. Using Zero-Knowledge Proofs (ZKPs) like zk-SNARKs or BBS+ Signatures, a holder can derive a minimal, cryptographically sound presentation that proves:

• "I am over 21" without revealing their exact birthdate
• "I am a licensed physician" without revealing their license number
• "My account balance exceeds $X" without revealing the exact balance

This prevents unnecessary data exposure and supports data minimization principles.

The credential is structured using a universal, machine-readable JSON-LD (JSON for Linked Data) format. This ensures interoperability across different vendors, wallets, and verifying platforms. The data model includes:

• @context: A URI defining the semantic vocabulary used (e.g., schema.org)
• type: An array defining the credential's classification
• credentialSubject: The claims being made about the subject
• proof: The embedded cryptographic signature object

This semantic richness allows machines to understand the meaning of the claims, not just the raw data.

Trust is not static. The framework includes mechanisms to revoke a credential before its natural expiration date. Common revocation strategies include:

• Revocation Lists (Bitstring Status List v1.0): A compressed, privacy-preserving bitstring published by the issuer where a specific bit index represents the revocation status of a credential.
• Verifiable Data Registries: Using distributed ledgers or Transparency Logs to record revocation events immutably.
• Short-Lived Credentials: Issuing credentials with a very short validFrom/validUntil window, requiring frequent re-issuance.

A verifier must always check the credential's status against the issuer's revocation registry.

The credential is held and controlled by the subject, not the issuer. The holder stores the credential in a digital wallet (often an edge agent on a mobile device) and decides when and to whom to present it. The presentation process involves:

• The verifier sending a proof request specifying required claims
• The holder constructing a Verifiable Presentation containing the necessary credentials and proofs
• The holder signing the presentation to prove possession of the credential

This establishes a triangular trust model (Issuer-Holder-Verifier) where the holder is an active, consenting participant.