Verifiable Credential

The W3C Verifiable Credentials Data Model v1.1 defines three distinct roles that form a decentralized trust triangle:

• Issuer: An authoritative entity (e.g., a university, government, or employer) that asserts claims about a subject and cryptographically signs a VC.
• Holder: The subject who stores the credential in a digital wallet and controls its presentation. The holder decides which claims to disclose.
• Verifier: The relying party that requests proof of specific claims and cryptographically validates the issuer's signature and the credential's revocation status.

This architecture eliminates the need for the verifier to contact the issuer directly, enabling offline verification and breaking reliance on centralized identity providers.

VCs derive their trust from advanced cryptographic proofs, not from the security of a centralized database. The standard supports multiple proof types:

• External Proof (Embedded): A JSON Web Token (JWT) signed using JWS (JSON Web Signature). The credential is a compact, URL-safe string easily passed in HTTP headers.
• Linked Data Proofs: Signatures (e.g., Ed25519Signature2020) embedded directly in the JSON-LD document. This method preserves the semantic graph structure and enables zero-knowledge proofs.
• BBS+ Signatures: A specific linked data proof suite that enables selective disclosure. A holder can derive a proof revealing only a subset of the original claims (e.g., proving age > 21 without revealing birthdate).

The choice of proof mechanism directly impacts the privacy properties and computational overhead of the verification process.

A Verifiable Credential is meaningless without a trusted identifier for the issuer. VCs are anchored to Decentralized Identifiers (DIDs) , which are globally unique, persistent URIs that require no centralized registration authority.

• A DID (e.g., did:web:example.com) resolves to a DID Document stored on a verifiable data registry (a blockchain, distributed ledger, or web server).
• This document contains the issuer's public keys and service endpoints.
• A verifier resolves the DID to fetch the public key needed to check the VC's signature, establishing a cryptographic root of trust without relying on a DNS-based PKI.

This binding ensures that the credential's authenticity is mathematically verifiable against a tamper-evident, user-controlled infrastructure.

A core privacy-preserving feature of advanced VC systems is the ability to answer a binary question without revealing the underlying data. This is achieved through Zero-Knowledge Proofs (ZKPs) .

• Predicate Proofs: A holder can prove a condition is met (e.g., age >= 18) without disclosing the actual dateOfBirth claim.
• Selective Disclosure: Using schemes like BBS+, a holder can reveal only specific claims from a multi-claim credential. A verifier receives a derived proof that is unlinkable to the original credential.
• Unlinkability: A verifier cannot collude with the issuer to correlate a presentation back to the original issuance event, preventing the creation of a surveillance graph.

This transforms the VC from a simple digital certificate into a minimal disclosure token, enforcing the principle of data minimization.

Trust requires the ability to revoke a credential (e.g., a driver's license is suspended). The VC standard avoids centralized Online Certificate Status Protocol (OCSP) stapling by using privacy-preserving revocation registries:

• StatusList2021: A bitstring-based list published by the issuer. Each credential is assigned a specific index. The issuer flips the bit to revoke it. A verifier downloads the compressed list and checks the bit, without revealing which credential they are checking to the issuer.
• Revocation Registries: The credential contains a credentialStatus property pointing to a verifiable data registry. This enables offline verification of revocation status if the list is cached.
• Cryptographic Accumulators: Advanced methods allow a holder to generate a non-revocation witness, proving their credential is not in a revoked set without revealing the set's size or contents.

This infrastructure ensures that trust is dynamic and can be withdrawn efficiently without compromising holder privacy.

A Verifiable Presentation (VP) is the envelope a holder constructs to share data with a verifier. It is a signed wrapper around one or more VCs, ensuring integrity and holder consent.

• Composition: A VP can combine claims from multiple VCs issued by different authorities (e.g., a passport VC and a university degree VC) into a single package.
• Holder Binding: The VP is signed by the holder's DID, proving possession of the private key associated with the credential's subject identifier. This prevents replay attacks.
• Domain & Challenge: A verifier can include a challenge (nonce) and a domain in their request. The holder includes these in the VP signature, proving the presentation was freshly generated for that specific verifier and preventing cross-domain replay.

The VP is the final, verifiable artifact that completes the trust transaction.

A non-transferable digital token representing the commitments, credentials, and affiliations of a person or entity. SBTs are a blockchain-native concept for expressing non-financialized reputation.

• Permanently bound to a specific blockchain address (the 'Soul')
• Cannot be sold or transferred, preventing reputation marketplaces
• Complements Verifiable Credentials by anchoring social provenance on-chain

A decentralized cryptographic model for establishing the authenticity of a public key binding by relying on a network of individual endorsements instead of a central certificate authority.

• Users sign each other's keys to build a trust graph
• Contrasts with the hierarchical PKI model used in traditional X.509 certificates
• Forms the conceptual basis for decentralized reputation and credential attestation networks

A cryptographically signed statement made by a trusted third party vouching for the accuracy or validity of a specific piece of reputation data regarding an entity.

• Functions as a Verifiable Credential specifically for trust scores or behavioral claims
• Enables reputation portability across platforms without revealing raw interaction data
• Can be combined with zero-knowledge proofs to disclose reputation thresholds privately