W3C Verifiable Credentials

A Verifiable Credential is secured through digital signatures and cryptographic proofs, enabling any third-party verifier to independently confirm the credential's authenticity and integrity without contacting the original issuer. The proof mechanism—commonly using Linked Data Proofs or JSON Web Tokens (JWTs)—binds the credential's claims to the issuer's Decentralized Identifier (DID) or public key. This creates a tamper-evident envelope where any post-issuance modification immediately invalidates the signature. Verifiers can cryptographically establish:

• The credential was issued by a specific, identifiable entity
• The claims within have not been altered since issuance
• The credential has not been revoked (via revocation registries)

VCs are fundamentally designed to operate without a centralized registry or identity provider. Instead, they leverage Decentralized Identifiers (DIDs)—a W3C standard for globally unique, resolvable identifiers that are not tied to any centralized authority. Each participant (issuer, holder, verifier) controls their own DID and associated cryptographic keys. This architecture eliminates single points of failure and enables self-sovereign identity models where:

• Issuers sign credentials with keys they fully control
• Holders store credentials in wallets they manage
• Verifiers resolve DIDs through distributed ledger networks or other verifiable data registries
• No intermediary can revoke or deny access to the identity infrastructure

A critical privacy-preserving property of VCs is the ability for holders to reveal only the minimum necessary information to a verifier. This is achieved through selective disclosure mechanisms and advanced Zero-Knowledge Proofs (ZKPs) such as BBS+ signatures or Camenisch-Lysyanskaya (CL) signatures. Rather than presenting an entire credential, a holder can:

• Prove they are over 21 without revealing their exact birthdate
• Demonstrate membership in an organization without exposing their member ID
• Show a credential is valid without disclosing the issuing authority This property directly addresses the principle of data minimization required by regulations like GDPR.

The VC data model provides a universal, machine-readable structure that is syntax-agnostic and can be serialized into multiple formats including JSON, JSON-LD, and CBOR. This standardization ensures that credentials issued by one system can be verified by any other compliant system, regardless of the underlying technology stack. The core data model defines:

• @context: A JSON-LD context that maps terms to globally unambiguous IRIs
• type: One or more credential types defining the credential's schema
• credentialSubject: The entity about which claims are made
• issuer: The DID or URI of the issuing entity
• proof: One or more cryptographic proofs securing the credential This semantic interoperability is essential for cross-domain trust ecosystems spanning education, healthcare, finance, and supply chain.

VCs incorporate explicit mechanisms for credential lifecycle management, ensuring that verifiers can determine whether a credential remains valid at the time of presentation. The standard supports multiple revocation strategies:

• Revocation Registries: Cryptographically signed lists or bitstring accumulators (e.g., RevocationList2020) that issuers update when credentials are revoked
• Status Lists: Compressed, privacy-preserving bitstring representations where each credential occupies a single bit indicating active or revoked status
• Expiration Dates: The validUntil property provides a deterministic expiration point
• Credential Refresh: Protocols for holders to obtain updated credentials without full re-issuance These mechanisms prevent the use of stale or revoked credentials without requiring verifiers to contact issuers in real-time.

A VC becomes verifiably linked to its legitimate holder through holder binding mechanisms that prevent credential theft and replay attacks. This is typically accomplished by embedding the holder's DID or public key directly within the credential's credentialSubject.id field. During presentation, the holder must prove control over the bound identifier through a cryptographic challenge-response protocol—signing a nonce provided by the verifier with the private key corresponding to the bound DID. This establishes:

• The presenter is the legitimate subject of the credential
• The credential was not intercepted and replayed by a malicious actor
• Biometric or possession-based binding can be layered for high-assurance scenarios Without holder binding, a stolen credential file could be presented by anyone.

A cryptographic technique that enables selective disclosure within Verifiable Credentials. A holder can prove a specific claim is true without revealing the underlying data.

• BBS+ Signatures: Enables deriving proofs that reveal only necessary attributes
• CL Signatures: Camenisch-Lysyanskaya scheme for privacy-preserving credentials
• Proves statements like "age > 21" without revealing birthdate
• Critical for GDPR-compliant identity systems

ZKPs transform VCs from simple attestations into privacy-respecting credentials suitable for sensitive use cases like healthcare and finance.

The data structure a holder constructs when sharing credentials with a verifier. A Verifiable Presentation packages one or more VCs and signs them to prove possession.

• Contains a proof signed by the holder's DID
• Can aggregate credentials from multiple issuers
• Supports non-repudiation through holder binding
• May include a challenge nonce to prevent replay attacks

This mechanism ensures that only the legitimate holder can present credentials, preventing unauthorized credential sharing and impersonation.

A mechanism for issuers to signal that a previously issued credential is no longer valid. Unlike X.509 certificates, VC revocation is privacy-preserving and does not require contacting the issuer in real-time.

• StatusList2021: Bitstring-based revocation using compressed lists
• RevocationBitmap: Efficient on-chain revocation for blockchain-based systems
• Verifiers check revocation status during presentation verification
• Supports both temporary suspension and permanent revocation

Effective revocation is essential for enterprise deployments where credentials must reflect real-world status changes, such as expired certifications or revoked access rights.

The canonicalization and signing mechanism that ensures Verifiable Credentials are cryptographically verifiable regardless of JSON key ordering or whitespace differences.

• Uses RDF Dataset Canonicalization (URDNA2015) to normalize data
• Applies LD-Proof signatures over the canonical form
• Enables cross-platform verification without data transformation issues
• Supports multiple signature suites: Ed25519, P-256, BBS+

This solves the fundamental problem of signing JSON-LD documents where semantically identical data can have different serializations.

The mapping between Verifiable Credentials and Schema.org structured data vocabularies, bridging decentralized identity with search engine knowledge graphs.

• Credential types align with Schema.org Person, Organization, and CreativeWork entities
• Enables search engines to parse and validate content creator credentials
• Supports author, creator, and publisher property assertions
• Forms the foundation for Generative Engine Optimization authority signals

This integration allows VCs to serve as machine-verifiable authority signals that AI systems can consume when determining content trustworthiness and provenance.