Verifiable Credential

Every Verifiable Credential contains a digital signature or zero-knowledge proof that cryptographically binds the credential to its issuer. This proof enables any verifier to independently confirm:

• The credential's integrity (it hasn't been altered).
• The credential's authenticity (it was issued by the claimed entity).
• The credential's validity status (e.g., not revoked). This eliminates the need to call the issuer for verification in most cases.

A holder can prove specific claims from a credential without revealing the entire document. For example, from a driver's license VC, one could prove they are over 21 without disclosing their exact birth date, address, or license number. This is achieved through techniques like:

• BBS+ Signatures for predicate proofs.
• Zero-Knowledge Proofs (ZKPs) for complex statements. This minimizes data exposure and enhances user privacy.

The issuer, holder, and verifier in a VC ecosystem are typically identified by Decentralized Identifiers (DIDs). A DID is a URI that points to a DID Document containing public keys and service endpoints. Key properties:

• Decentralized: No central registration authority is required.
• Controller-owned: The entity it identifies has cryptographic control.
• Verifiable: Enables trusted interactions without intermediaries. DIDs provide the foundational layer of trust for VCs.

VCs follow the W3C Verifiable Credentials Data Model, ensuring interoperability across different systems and vendors. The model defines core components:

• Metadata: Issuer, issuance date, expiration, credential type.
• Claims: The actual statements about the subject (e.g., "degreeType": "Bachelor").
• Proofs: The cryptographic proof section. This standardization is crucial for creating a portable, vendor-neutral credential ecosystem.

Unlike traditional credentials stored in an issuer's database, a VC is issued to and stored by the holder (e.g., in a digital wallet). The holder decides:

• Where to store it (custodial or non-custodial wallet).
• When to present it and to which verifier.
• What to disclose using selective disclosure. This shifts the paradigm from institution-centric to user-centric data control.

VCs are designed for machine readability and automated verification. The structured data and standard proofs allow software systems to:

• Parse credential contents unambiguously.
• Verify cryptographic proofs algorithmically.
• Exchange credentials across different platforms (e.g., an education VC from University A being accepted by Employer B). This automation enables scalable trust in digital interactions.

A Verifiable Credential is a cryptographically signed, machine-verifiable attestation about a subject (e.g., a person, organization, or thing). It is composed of three key parts:

• Metadata: Describes the credential type, issuer, and issuance date.
• Claims: The actual data or attributes being asserted (e.g., age > 18, KYC status = verified).
• Proofs: The digital signature (e.g., using EdDSA or BBS+) that enables cryptographic verification of the issuer's authenticity and the credential's integrity.

VCs are typically bound to a Decentralized Identifier (DID), a self-sovereign identifier controlled by the credential holder. This creates a portable identity layer independent of centralized registries.

• Holder Control: The user's DID, stored in a digital wallet, acts as the anchor for all their credentials.
• Selective Disclosure: Users can prove specific claims from a VC (e.g., that they are over 21) without revealing the entire credential or their master DID, using zero-knowledge proofs.

In DeFi, VCs enable permissioned yet privacy-preserving access to protocols.

• Example: A user obtains a VC from a licensed issuer proving they are an accredited investor or have completed KYC. They can then present a cryptographic proof of this credential to access a regulated DeFi pool without exposing their personal data on-chain.
• This solves the compliance trilemma by meeting regulatory requirements while preserving user privacy and maintaining decentralization.

VCs are a primary tool for Sybil resistance in decentralized autonomous organizations (DAOs) and airdrop distributions.

• Proof-of-Personhood: Issuers can provide a VC attesting to a unique human identity. This prevents single entities from accumulating excessive voting power or farming tokens with multiple wallets.
• Contribution Credentials: DAOs can issue VCs for specific contributions (e.g., completing a bounty, attending meetings), which can be used to weight governance votes or allocate rewards fairly.

Adoption relies on open standards to ensure credentials are portable across different ecosystems.

• W3C VC Data Model: The World Wide Web Consortium's standard defines the core data model and syntax for VCs.
• DID Methods: Different blockchains (Ethereum, Sovrin, ION) implement their own DID methods for creating and resolving identifiers, but all aim for interoperability through the core W3C specifications.

The Trust Triangle model defines the three roles in a VC ecosystem:

1. Issuer: The authoritative entity that creates and signs the credential.
2. Holder: The subject who receives and stores the credential in their wallet.
3. Verifier: The entity that requests and cryptographically verifies the credential. A Verifiable Presentation is the package a holder sends to a verifier, containing one or more VCs and proofs, fulfilling a specific request (e.g., "prove you are over 18").

A user can aggregate their credit history from multiple traditional and alternative sources (e.g., bank loans, on-chain DeFi activity, utility payments) into a single, cryptographically signed VC. This creates a portable financial identity they can present to any lender without the lender needing to query a central bureau. The VC proves the data's origin and integrity while allowing the user to selectively disclose only relevant parts.

An employer or payroll provider can issue a verifiable credential attesting to an employee's role, tenure, and salary. The employee holds this VC in their digital wallet and can present it during a loan application. This streamlines underwriting by providing tamper-proof proof of income, reducing fraud and manual document checks. The credential can be configured to reveal only that income exceeds a threshold without disclosing the exact figure.

For collateralized lending, a user can obtain a VC from a custodian or via a zero-knowledge proof attesting to their ownership and the value of an asset (e.g., real estate, tokenized securities, cryptocurrency holdings) without transferring custody. This VC, containing a cryptographic commitment to the asset details, allows the lender to confidently underwrite a loan based on verifiable collateral, enabling more complex financial products.

Protocols and DAOs can issue VCs representing a user's on-chain reputation, such as successful repayment history, governance participation, or long-term holding of specific assets. These soulbound tokens (SBTs) or similar non-transferable VCs become a component of decentralized credit scores. Lenders can use these to assess trustworthiness and offer better terms to users with proven, verifiable track records in specific ecosystems.

A regulated entity performs Know Your Customer (KYC) checks once and issues a VC confirming the user's identity and that AML screening is complete. The user stores this VC and can present it to multiple DeFi protocols or lenders, each verifying the attestation's signature from the trusted issuer. This creates privacy-enhanced compliance, as the user doesn't re-submit sensitive documents, and lenders avoid redundant, costly checks.

Property managers or utility companies can issue VCs for tenants who pay rent and bills on time. This creates an alternative data trail for thin-file borrowers (those with limited traditional credit history). When applying for credit, the user can present these VCs to demonstrate responsible financial behavior, helping lenders build a more complete risk profile and potentially expanding access to credit.

A DID Document is a JSON-LD document that describes the cryptographic material, verification methods, and service endpoints associated with a Decentralized Identifier (DID). It is the machine-readable data structure resolved from a DID.

• Contents: Contains public keys, authentication mechanisms, and service endpoints (e.g., for credential issuance).
• Verification: Provides the necessary public keys to verify proofs, such as digital signatures on a Verifiable Credential.
• Immutable Link: The DID Document is cryptographically bound to its DID, ensuring the identifier's integrity.

A Verifiable Presentation is a tamper-evident container, often a signed JSON object, that bundles one or more Verifiable Credentials for sharing with a verifier. It is how a holder selectively discloses credentials.

• Purpose: Allows the holder to prove control over the credentials and present specific claims without revealing the entire credential.
• Proof: Contains a cryptographic proof from the holder (and optionally from the issuer) that verifies the integrity and origin of the presented data.
• Selective Disclosure: Enables techniques like presenting only a subset of claims or providing zero-knowledge proofs.

A Zero-Knowledge Proof (ZKP) is a cryptographic method by which one party (the prover) can prove to another party (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself.

• Application to VCs: Enables selective disclosure and privacy-preserving verification. A holder can prove they have a credential meeting certain criteria (e.g., "is over 21") without revealing their exact birth date or the full credential.
• Types: Used in advanced credential formats like W3C's Data Integrity Proofs or AnonCreds to enhance privacy.

A Trust Registry is a decentralized, auditable list that defines which entities are authorized to act as issuers or verifiers within a specific ecosystem or for specific credential types. It establishes the root of trust.

• Function: Helps verifiers determine if an issuer's DID is trusted to issue a particular credential schema.
• Decentralization: Can be implemented on a blockchain, a decentralized web node, or other verifiable data structures to avoid a single point of control.
• Governance: Managed by a governance framework or consortium relevant to the credential's domain (e.g., education, healthcare).

A Credential Schema is a blueprint that defines the structure, data types, and semantic meaning of the claims contained within a Verifiable Credential. It ensures interoperability between issuers and verifiers.

• Standardization: Specifies the property names (e.g., degreeType, issuanceDate) and their expected value formats.
• Reference: Credentials reference their schema via a URI, allowing verifiers to fetch and validate the expected structure.
• Example: A university's diploma credential would use a schema defining fields for studentName, degreeAwarded, and graduationDate.