Wiki · Concept · Last reviewed June 25, 2026

Digital Credentials API

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

Category: Concept Updated: June 25, 2026 Tags: digital identity, credentials, wallets, browsers, AI governance

Definition

The Digital Credentials API is a W3C Working Draft that specifies an API for user agents to mediate presentation and issuance of digital credentials. The current W3C publication history lists a Working Draft dated June 26, 2026. The draft says the API builds on Credential Management Level 1 and is designed to be agnostic to credential formats.

The API is not a credential format, wallet format, identity proofing standard, or finished Recommendation. It is a proposed web platform interface. 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.

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 can make a credential request, the browser can mediate 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 describes platform-provided user experience for credential and credential-manager selection.

Protocol Boundary

The API separates browser mediation from the particular presentation or issuance protocol. A request can include 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 a set of protocols, wallet managers may support others, and credential formats may evolve separately. W3C's draft lists org-iso-mdoc as a presentation protocol value, and it treats the protocol list as evolving. 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.

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.

Governance Risks

The first risk is request proliferation. The W3C draft explicitly discusses the risk of unnecessary requests for government and non-government credentials. Once a request ceremony becomes easy, websites can normalize credential checks for low-stakes interactions.

The second risk is correlation. The draft's privacy material discusses verifier-verifier linkability and the need for unlinkable exchanges between verifiers and credential managers. If a browser prompt repeatedly exposes stable identifiers or rich attributes, it can turn privacy-preserving credentials into tracking infrastructure.

The third risk is blurred responsibility. The draft says implementation of credential managers, digital wallets, operating systems, platform security, and transport layers is outside parts of the API's scope. A relying party still needs policy for verifier authorization, credential minimization, issuer trust, wallet compromise, revocation, and appeal.

Governance 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-style presentation protocols, platform wallets, and the Digital Credentials API are related but not interchangeable.

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