Verifiable Credential (VC)

A globally unique, persistent identifier that requires no centralized registration authority. DIDs are the foundational identity layer for VCs, enabling entities to authenticate and prove control over their credentials.

• DID Document: A JSON-LD file containing public keys and service endpoints
• DID Methods: Define how DIDs are created, read, and updated on specific ledgers (e.g., did:web, did:ethr)
• Self-Sovereign Identity: Users control their identifiers without relying on external administrators

A pairing-based digital signature scheme that allows a credential holder to reveal only specific attributes from a signed credential while maintaining cryptographic integrity. The verifier receives mathematical proof of the disclosed claims without ever seeing the hidden data.

• Unlinkable Presentations: Each presentation generates a fresh proof, preventing correlation
• Zero-Knowledge: The verifier learns nothing beyond the explicitly revealed attributes
• Compact Proofs: Signature size remains small regardless of the number of attributes

A system that mediates the creation, verification, and management of DIDs and credential schemas. It serves as a trusted source for checking credential status, revocation, and issuer authorization.

• Revocation Registry: Maintains a list of revoked credentials without revealing holder identities
• Trusted Ledgers: Often implemented on distributed ledgers like Ethereum or Hyperledger Indy
• Status List 2021: A W3C specification for compact, privacy-preserving credential status checks

Every VC embeds a cryptographic proof object that binds the credential's claims to the issuer's DID. This creates an unbroken chain of trust from the credential back to the issuer's public key material.

• Linked Data Proofs: Embed the proof directly in the credential using JSON-LD normalization
• JWT Proofs: Encode the credential as a JSON Web Token signed with the issuer's private key
• Proof Sets: Multiple proofs can be attached, enabling multi-signature and threshold approval workflows

VCs are designed to minimize data exposure during verification. The holder generates a verifiable presentation that packages only the necessary claims and proofs for a specific interaction, preventing over-sharing.

• Holder Binding: Presentations can include a proof of possession to bind the credential to the presenter
• Domain & Challenge: Fresh nonces prevent replay attacks and ensure the presentation is generated for a specific verifier
• Minimal Disclosure: Only the exact attributes required for the transaction are revealed

Issue a Verifiable Credential that cryptographically binds a model's transparency documentation to its unique identifier. This allows downstream consumers to automatically verify the provenance and stated performance characteristics of a model before deployment.

• Issuer: A compliance officer or certified testing lab
• Subject: A specific model version hash
• Claims: Fairness metrics, intended use, out-of-scope applications
• Benefit: Replaces static PDFs with machine-readable, instantly verifiable trust signals

Establish a Decentralized Public Key Infrastructure (DPKI) for AI auditors. A national accreditation body issues a VC to a certified auditor, who can then present a Zero-Knowledge Proof derived from that credential to prove their authority without revealing their full identity.

• Enables pseudonymous, privacy-respecting audit submissions
• Allows for real-time revocation of auditor access if credentials expire
• Creates a cryptographically verifiable chain of trust from regulator to auditor to audit report

Generate a Verifiable Credential representing the final state of an AI audit trail. The credential contains a cryptographic commitment to the log's integrity, such as a Merkle Root, and is anchored to a public Transparency Log or blockchain.

• Proof of Existence: Proves the log existed at a specific point in time
• Tamper Evidence: Any alteration to the log invalidates the VC's signature
• Selective Disclosure: Auditors can reveal specific log entries without exposing the entire dataset

Issue VCs as cryptographically verifiable consent receipts to data subjects. When training data is ingested, an AI pipeline can verify these credentials to ensure purpose limitation and lawful basis for processing.

• Subject: A data subject's identifier
• Claims: Permitted processing activities, retention period, jurisdiction
• Integration: Data loaders verify the VC signature and check revocation status before ingestion
• Compliance: Provides a direct, auditable link between consent and model training data

In a multi-party AI supply chain, a model provider can present a Verifiable Presentation aggregating multiple VCs from different auditors. A procuring enterprise verifies all credentials against a trusted Verifiable Data Registry in a single automated step.

• Aggregated Claims: Security audit, bias evaluation, and data provenance in one package
• Revocation Checking: Automatically queries the registry to ensure no credential has been revoked
• Zero-Trust Architecture: Eliminates the need for bilateral legal agreements for basic compliance checks

Assign a Decentralized Identifier (DID) and corresponding VC to each autonomous AI agent in a multi-agent system. Agents present their credentials to establish trust before engaging in task delegation or data exchange.

• Claims: Agent capabilities, safety constraints, operator identity
• Interaction: Agent-to-agent authentication via BBS+ Signatures for selective disclosure
• Governance: Enforces a policy-driven, cryptographically verifiable trust mesh between heterogeneous agents