Verifiable Credential

The credential's integrity is secured through digital signatures and cryptographic hashing. Any post-issuance modification to a claim immediately invalidates the signature. This mechanism relies on public-key infrastructure where the issuer signs the credential with their private key, and any verifier can validate it using the issuer's publicly available Decentralized Identifier (DID) document.

• Uses Linked Data Proofs or JSON Web Tokens (JWTs) for securing payloads
• Enables non-repudiation: an issuer cannot credibly deny having issued a credential
• Supports Merkle tree-based selective disclosure for revealing only specific claims

VCs do not rely on a central certificate authority. Instead, the issuer and subject are identified by DIDs—globally unique, persistent identifiers that are cryptographically verifiable. A DID resolves to a DID Document stored on a distributed ledger or decentralized network, containing the public keys necessary for authentication.

• Eliminates single points of failure inherent in centralized PKI hierarchies
• Enables self-sovereign identity: subjects control their own identifiers without administrative intermediaries
• Supports DID rotation for key management without losing the credential's historical verifiability

Advanced VC implementations leverage Zero-Knowledge Proofs to enable a holder to prove a claim about their data without revealing the underlying data itself. For example, a holder can cryptographically prove they are over 21 without disclosing their exact birthdate. This is implemented using schemes like BBS+ signatures and Camenisch-Lysyanskaya (CL) signatures.

• Predicate proofs: prove age > 21 without revealing dateOfBirth
• Minimizes data exposure in compliance with data minimization principles under GDPR
• Reduces correlatability by preventing verifiers from accumulating unique identifiers

Unlike traditional models where a verifier pulls data from a central database, the holder of a VC actively constructs and transmits a Verifiable Presentation. This presentation bundles one or more VCs and signs them with the holder's DID, proving possession and consent. The holder chooses which credentials to share and with whom.

• Prevents unauthorized background checks by requiring explicit holder consent
• Supports compound proofs that combine claims from multiple issuers into a single presentation
• Decouples the act of credential issuance from the act of credential verification

Every VC references a @context and a credentialSchema. The @context maps JSON keys to globally unambiguous URIs, ensuring semantic interoperability. The credentialSchema defines the data structure and validation rules for a specific credential type, enabling automated verification without human interpretation.

• Uses JSON-LD for linked data semantics and vocabulary mapping
• Enables automated schema validation before cryptographic verification
• Supports industry-standard schemas like W3C VC Data Model v1.1 and domain-specific extensions

VCs support privacy-preserving revocation mechanisms that do not require a verifier to call back to a centralized issuer API. Common methods include Revocation Registries (cryptographic accumulators) and Status List 2021 bitstring registries. A verifier checks a compact, publicly hosted list to confirm a credential has not been revoked without revealing which specific credential they are checking.

• Bitstring Status List: a compressed bit array where each credential occupies a single bit
• Cryptographic Accumulators: allow revocation checks via a single witness value without scanning a list
• Prevents issuer tracking of verification events, preserving holder privacy