Wiki · Concept · Last reviewed June 25, 2026

Verifiable Credentials

Verifiable credentials are a W3C data model for tamper-evident digital claims that can move from issuers to holders to verifiers, making them relevant to identity, provenance, delegation, and agent governance.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: digital identity, credentials, provenance, AI governance, wallets

Definition

A verifiable credential, or VC, is a structured digital credential whose authorship and integrity can be checked by a verifier. The W3C Verifiable Credentials Data Model v2.0 became a W3C Recommendation on May 15, 2025. It defines an extensible way to express claims, credentials, and presentations in an ecosystem made up of issuers, holders, and verifiers.

A VC can help a verifier check who issued a claim, whether the credential has been altered, and whether it is still usable under the verifier's policy. It does not prove that the issuer is trustworthy, that the underlying claim is true or fair, that the holder is the rightful presenter, or that the verifier has a legitimate reason to ask for it.

VCs are a data model and ecosystem pattern, not one identity system. A deployment might use Decentralized Identifiers, OpenID protocols, SD-JWT, JOSE, COSE, BBS-derived selective-disclosure proofs, mobile-document formats, browser mediation, or vendor wallets. The governance question is which exact layer is making which claim.

Snapshot

Current Context

In the June 2026 standards landscape, VCDM v2.0 remains the W3C Recommendation baseline, while Verifiable Credentials Data Model v2.1 is a W3C Working Draft dated May 11, 2026. W3C also published a Verifiable Credentials Overview Group Note on June 18, 2026 and a Threat Model for Decentralized Credentials Group Note Draft on June 22, 2026. Those documents help explain ecosystem risks, but they are not replacements for the normative data model and securing specifications.

Adjacent specifications are at different maturity levels. Data Integrity 1.0, Securing Verifiable Credentials using JOSE and COSE, and Bitstring Status List v1.0 are W3C Recommendations from May 15, 2025. Data Integrity BBS Cryptosuites v1.0 was a W3C Candidate Recommendation Draft dated April 7, 2026, aimed at selective disclosure and unlinkable derived proofs. Confidence Method v1.0 was a W3C Working Draft dated June 18, 2026 and explicitly experimental.

Transport and wallet protocols have also matured outside W3C. OpenID for Verifiable Presentations 1.0 became an OpenID Final specification on July 9, 2025, and OpenID for Verifiable Credential Issuance 1.0 became Final on September 16, 2025. IETF RFC 9901 standardized Selective Disclosure for JSON Web Tokens in November 2025, while the SD-JWT VC profile remained an IETF Internet-Draft during this review window. A verifier therefore needs to distinguish credential data model, credential format, issuance protocol, presentation protocol, wallet behavior, and trust framework.

Roles and Objects

An issuer creates a credential. A holder stores or controls it, often through a wallet or credential-management system. A verifier receives a presentation and decides whether it satisfies a policy. The credential subject is the entity the claims are about; depending on the schema, that subject may be a person, organization, account, device, product, dataset, model, or service.

A credential is a set of claims plus metadata such as issuer, subject, validity period, type, schema, status, evidence, and terms of use. A verifiable credential is secured so verification software can detect tampering and check authorship. A verifiable presentation packages one or more credentials for a verifier, often adding holder binding or proof of possession so the presentation is not merely a copied document.

This portability lets an institution issue a claim once and let another system evaluate it later. It also creates governance pressure: schema, issuer authority, revocation, retention, and appeal all matter.

Securing and Status

W3C separates the data model from securing mechanisms. Verifiable Credential Data Integrity 1.0, also a May 15, 2025 W3C Recommendation, describes cryptographic proof mechanisms for authenticity and integrity. Securing Verifiable Credentials using JOSE and COSE, another Recommendation from the same date, defines ways to secure VC data with JOSE, SD-JWT, and COSE technologies.

Status is separate from signature checking. Bitstring Status List v1.0, a W3C Recommendation from May 15, 2025, defines a privacy-preserving and space-efficient way to publish suspension, revocation, or similar status information. A credential can be correctly signed and still be expired, suspended, revoked, superseded, or outside the verifier's policy.

Schemas and evidence are also separate. A credential schema can help software understand expected fields and types; evidence can point to supporting material; neither is a guarantee that the issuing process was fair or that the evidence was independently reviewed. For high-stakes use, the verifier needs a policy that names acceptable issuers, schemas, assurance levels, status methods, freshness windows, and appeal routes.

AI Context

For AI systems, verifiable credentials are not only about human identity documents. They are a candidate format for attestations about agents, datasets, model releases, benchmark runs, audits, licensing, safety cases, device provenance, and software supply-chain claims.

The connection to AI Agent Identity is direct. As AI agents act through browsers, APIs, wallets, tool servers, and other agents, systems need a way to distinguish self-description from accountable claims. A signed agent card, bot registration, product passport, or audit attestation still needs policy about who may issue it and what relying parties may infer.

The W3C Digital Credentials API is Working Draft work, not a final Recommendation, and is designed to let user agents mediate issuance and presentation while remaining agnostic to credential formats. That matters for browser agents: a credential prompt is not just another click target. It can disclose identity, eligibility, affiliation, location-bound status, or government-linked attributes.

For AI provenance, VCs sit beside Content Provenance and Watermarking, AI Data Provenance, SCITT, AI Audits and Third-Party Assurance, and AI System Inventory. A VC can carry a signed claim about an artifact or actor; a transparency log, model card, audit trail, or procurement record may still be needed to make that claim useful.

Governance and Safety

VC systems fail when cryptographic verification is treated as institutional truth. A valid signature says that a key associated with an issuer protected a credential; it does not settle whether the issuer should exist, whether the credential is accurate, or whether a verifier is over-collecting attributes.

Selective disclosure and zero-knowledge techniques can reduce unnecessary sharing, but they are not automatic. A system can use VCs and still demand too much data, create linkable presentations, centralize wallet dependencies, exclude people without credentials, or make revocation opaque.

For AI governance, a dataset credential, model attestation, or agent authorization should name the issuer, schema, subject, validity period, status mechanism, evidence basis, relying parties, and dispute path. Otherwise the VC becomes a polished label on an unreviewed claim.

Verifier governance is as important as issuer governance. A verifier should have authority to ask, request the minimum claim, authenticate itself to the wallet or holder, explain purpose and retention, check status without creating avoidable issuer or verifier correlation, and record the decision without storing unnecessary credential contents. These controls connect directly to Data Minimization and Contextual Integrity.

Credential Evidence Record

A VC-backed claim is useful only if later reviewers can reconstruct what was actually checked. For consequential identity, agent, provenance, or audit claims, preserve at least:

Defense Pattern

Source Discipline

Claims about verifiable credentials should identify the exact specification, version, maturity level, and securing mechanism. VCDM v2.0, VCDM v2.1, Data Integrity proofs, JOSE/COSE credentials, SD-JWT selective disclosure, SD-JWT VC, mobile identity documents, browser APIs, OpenID presentation flows, and vendor wallets are related but not interchangeable. A report should say what was issued, who issued it, how it was secured, how status was checked, what the verifier learned, and what policy authorized the request.

Use primary sources for standards and current status: W3C Recommendations, Working Drafts, Candidate Recommendations, Group Notes, OpenID Final specifications, IETF RFCs or Internet-Drafts, regulator text, and official implementation documentation. Do not cite a wallet vendor's marketing page as evidence that an ecosystem is privacy-preserving or interoperable.

For AI claims, avoid vague phrases like "the model is certified" or "the agent is verified." Name the credential issuer, subject, claim, schema, proof mechanism, status check, relying-party policy, and the external evidence that makes the credential meaningful.

Spiralist Reading

Spiralism reads verifiable credentials as a test of institutional memory. A credential can make a claim portable, but portability can either reduce dependency or spread classification everywhere. The healthy form is narrow, inspectable, revocable, and contestable. The unhealthy form turns every interaction into an identity checkpoint and every verifier into a collector of attributes.

Open Questions

Sources

Return to Wiki