Wiki · Concept · Last reviewed June 25, 2026

Digital Credentials API

The Digital Credentials API is W3C draft work on browser and user-agent mediation for presenting and issuing digital credentials, making the browser a policy surface between websites, wallets, issuers, holders, and verifiers.

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

Definition

The Digital Credentials API is a W3C Recommendation-track Working Draft that extends the web credential-management surface so user agents can mediate requests to present or issue digital credentials. The draft says the API builds on Credential Management Level 1 and is agnostic to credential formats.

The API is not a credential format, wallet format, identity proofing standard, trust framework, or finished W3C Recommendation. Its central move is to let a website ask through the browser, rather than hard-code a direct integration with every wallet, presentation protocol, issuance protocol, and mobile device path. That makes the browser part of the request ceremony: it can expose who is asking, what is being requested, which credential manager is involved, and whether the holder chooses to proceed.

Snapshot

Current Context

In the June 2026 standards landscape, the Digital Credentials API is changing quickly. W3C's publication history shows frequent 2026 Working Drafts, with the latest published draft dated June 26, 2026. W3C's status text says Working Draft publication does not imply W3C endorsement and that the document should be cited as work in progress.

Implementation status is separate from standards status. Chrome's developer documentation says the Digital Credentials API is enabled by default from Chrome 141 and supports same-device presentation on Android plus cross-device presentation on desktop Chrome. Even where a browser exposes the API, support depends on platform services, installed credential managers, credential formats, exchange protocols, and verifier code.

The adjacent protocol stack has matured outside the browser API itself. OpenID for Verifiable Presentations 1.0 became an OpenID Final specification on July 9, 2025 and defines a protocol for requesting and presenting credentials. OpenID for Verifiable Credential Issuance 1.0 became Final on September 16, 2025 and defines an issuance API. W3C's Digital Credentials draft can reference these protocols, but it does not make every OpenID4VP, OpenID4VCI, ISO mdoc, W3C Verifiable Credential, or wallet deployment interoperable by default.

Roles and Ceremony

Digital credential systems usually involve issuers, holders, verifiers, credential managers, and user agents. W3C's Verifiable Credentials Data Model v2.0 defines issuers, holders, verifiers, claims, credentials, and presentations; the Digital Credentials API borrows that vocabulary while focusing on the browser mediation layer.

In a presentation flow, a verifier website makes a credential request, the browser mediates selection, and a holder or credential manager, often a digital wallet, can return a response. In an issuance flow, the draft describes a mediated path for requesting issuance of a credential. The browser is therefore not merely a transport pipe. It becomes part of the consent, selection, protocol, and privacy boundary.

The draft requires transient activation for presentation or issuance requests, so sites cannot silently request or issue digital credentials without a user-triggered action. It also requires user mediation and describes platform-provided user experience for credential and credential-manager selection. Those controls reduce silent access, but they do not by themselves prevent dark patterns, over-requesting, or institutional pressure to disclose a credential.

Protocol Boundary

The API separates browser mediation from the particular presentation or issuance protocol. A request includes a protocol identifier and request data. The draft's DigitalCredential interface carries a protocol member and data member, while DigitalCredential.userAgentAllowsProtocol() lets a site ask whether the user agent allows a protocol identifier.

This protocol boundary is the point of the design. A browser may support one set of protocols, wallet managers may support another, and credential formats may evolve separately. W3C's draft enumerates openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, and org-iso-mdoc for presentation, plus openid4vci-v1 for issuance. That means implementers should not describe the API as "the W3C VC wallet API" or "the mDL API"; it is a mediation surface for multiple credential ecosystems.

The boundary also separates the Digital Credentials API from Federated Credential Management, WebAuthn, Verifiable Credentials, OpenID for Verifiable Presentations, and Decentralized Identifiers. Those layers can be used together, but a claim about one layer should not be used as evidence about another.

Agent Context

For AI systems, the Digital Credentials API matters wherever an agent operates inside a browser or browser-like automation environment. A purchasing agent, eligibility checker, travel assistant, insurance workflow, or customer-support agent might encounter a website that asks for age, license status, student status, citizenship attribute, professional credential, or organization authority.

The governance problem is delegation. If a human has a wallet and an AI agent operates the browser, who sees the prompt, who chooses the credential, who authorizes disclosure, and what is logged? Agent tooling should not treat credential presentation as another invisible browser action. A credential request can expose identity, eligibility, location-bound status, or government-linked attributes. It needs human-facing review, clear purpose, scoped disclosure, and audit records.

Agent systems should distinguish assistance from authority. An agent may summarize a verifier request, check whether it matches policy, or prepare a refusal. It should not silently present credentials unless the holder has already authorized that exact disclosure class, relying party, purpose, and retention rule.

Governance and Safety

The first risk is request proliferation. The W3C draft explicitly discusses unnecessary credential requests for government and non-government credentials and notes that verifiers may have incentives to over-request. Once a request ceremony becomes easy, websites can normalize credential checks for low-stakes interactions and exclude people who lack the requested wallet or document.

The second risk is correlation. The draft's privacy material discusses verifier-verifier linkability, verifier-issuer linkability, "phone home" mechanisms, status-check leakage, and incidental data leakage. If a browser prompt repeatedly exposes stable identifiers, rich attributes, wallet metadata, or credential availability, a privacy-preserving credential system can become tracking infrastructure.

The third risk is blurred responsibility. The draft says credential-manager implementation, wallet storage, platform security, and transport-layer details are outside parts of the API's scope. A relying party still needs policy for verifier authorization, credential minimization, issuer trust, wallet compromise, revocation, refusal, correction, and appeal.

The fourth risk is consent laundering. A browser prompt is not automatically meaningful consent, especially when access to work, benefits, travel, schooling, credit, housing, or public services depends on clicking through. Governance should treat the prompt as one evidence point inside a larger policy process, not as a substitute for legitimacy.

Ceremony Record

For consequential uses, preserve a compact record of the credential ceremony without hoarding the credential itself:

Defense Pattern

Source Discipline

Claims about the Digital Credentials API should name the draft date, browser or user-agent implementation, protocol identifier, credential format, wallet or credential manager, and verifier policy. Credential Management Level 1, Verifiable Credentials, mobile driving licenses, OpenID presentation and issuance protocols, platform wallets, WebAuthn, FedCM, and the Digital Credentials API are related but not interchangeable.

For implementation claims, cite the browser or platform's own documentation and state the exact browser version, operating-system dependency, wallet dependency, and whether the feature is presentation, issuance, or both. For governance claims, cite the request purpose, legal basis or institutional policy, retention rule, and appeal mechanism rather than relying on generic claims that the exchange is "privacy-preserving."

Spiralist Reading

Spiralism reads the Digital Credentials API as a ceremony layer. The humane version lets the browser slow down identity disclosure and make the request legible. The dangerous version makes credential presentation feel as routine as clicking "allow" on a cookie banner. Machine-mediated life needs stronger pause points, not smoother identity extraction.

Open Questions

Sources

Return to Wiki