Verifiable Credential

The integrity of a Verifiable Credential is secured through digital signatures using asymmetric cryptography. The issuer creates a hash of the credential's claims and signs it with their private key. Any subsequent modification to the data—even a single bit—invalidates the signature. Verifiers use the issuer's public Decentralized Identifier (DID) to cryptographically confirm the credential has not been altered since issuance. This mechanism provides mathematical certainty of data integrity without requiring trust in the storage intermediary.

Unlike traditional Public Key Infrastructure (PKI) which relies on centralized Certificate Authorities, VCs operate on a decentralized trust model. Issuers, holders, and verifiers can establish trust through Distributed Ledger Technology (DLT) or other verifiable data registries. This architecture eliminates single points of failure and censorship. A verifier does not need to contact the issuer to validate a credential; they only need access to the issuer's public DID Document, which can be resolved from a decentralized network like a blockchain or a distributed hash table.

Holders of VCs can reveal only the specific claims necessary for a transaction without exposing the entire credential. This is achieved through Zero-Knowledge Proofs (ZKPs) , specifically schemes like BBS+ signatures or Camenisch-Lysyanskaya (CL) signatures. For example, a holder can prove they are over 21 years old using a digital driver's license credential without revealing their exact birthdate, name, or address. This privacy-preserving mechanism is a fundamental departure from physical credentials, which force full disclosure upon presentation.

The W3C Verifiable Credentials Data Model v1.1 provides a universal, machine-readable structure for expressing claims. A VC is a JSON-LD document containing a @context array that maps terms to globally unique IRIs, a type field declaring it as a VerifiableCredential, a credentialSubject containing the claims, and a proof object with the cryptographic signature. This standardization ensures interoperability across different vendors, wallets, and verification systems, preventing vendor lock-in and enabling a global ecosystem of compatible tools.

The VC architecture places the holder—the subject of the credential—at the center of the data flow. Credentials are stored in a digital wallet controlled entirely by the holder, not on a centralized server. The holder decides when, where, and with whom to share their credentials. Issuers are not notified when a credential is presented for verification, preventing the issuer from tracking the holder's activities. This model enforces the principle of data minimization and aligns with self-sovereign identity (SSI) philosophies.

To invalidate a credential before its expiration, issuers employ privacy-respecting revocation mechanisms. The most common is a Revocation List or Status List 2021, a compressed bitstring published by the issuer. Each credential is assigned an index in this list; a flipped bit indicates revocation. A holder can present a non-revocation proof to a verifier without the verifier needing to directly query the issuer's server, preserving the holder's privacy and ensuring the verifier can confirm validity even if the issuer is temporarily offline.

A globally unique persistent identifier that does not require a centralized registration authority and is often generated cryptographically. DIDs are the foundational subject identifiers in a Verifiable Credential ecosystem, enabling the holder to prove control via a linked DID Document containing public key material. The W3C DID Core specification ensures interoperability across different distributed ledger and network implementations.

• Resolves to a DID Document with verification methods
• Enables self-sovereign identity without intermediaries
• Supports multiple methods: did:web, did:key, did:ethr

A cryptographic protocol where a prover can convince a verifier that a statement is true without revealing any information beyond the validity of the statement itself. In the context of Verifiable Credentials, ZKPs enable selective disclosure—a holder can prove they are over 21 without revealing their exact birthdate. This is critical for privacy-preserving compliance in automated content governance pipelines.

• Enables predicate proofs without raw data exposure
• Implemented via BBS+ signatures or zk-SNARKs
• Reduces data minimization liability under GDPR

A cryptographically secure mechanism for issuers to signal that a previously valid credential is no longer trustworthy without revealing the identities of affected holders. Modern implementations use bitstring status lists or accumulators rather than traditional Certificate Revocation Lists (CRLs) to preserve privacy. This is essential for automated content governance when author permissions or compliance certifications expire.

• StatusList2021: Compressed bitstring for bulk revocation
• Accumulator-based: ZKP-friendly revocation with no correlation risk
• Enables real-time credential validity checks in automated pipelines

The mechanism that cryptographically ties a Verifiable Credential to the specific entity presenting it, preventing replay attacks and credential theft. Binding is typically achieved by requiring the holder to prove possession of a private key corresponding to a public key embedded in the credential's credentialSubject. This ensures that a stolen credential cannot be used by an impersonator in automated verification workflows.

• Subject-Holder Relationship: Explicitly declared in the credential
• Proof of Possession: Challenge-response protocol during presentation
• Prevents man-in-the-middle credential injection attacks