W3C Digital Credentials API

The W3C Digital Credentials API is a browser API for requesting credentials from a digital identity wallet, extending the same navigator.credentials interface that FIDO2 (WebAuthn) uses for authentication. It exists because presenting a Verifiable Credential on the web previously meant handing the user off through a custom URL scheme or a QR code that the browser could neither inspect nor protect: any site could try to invoke a wallet, and the wallet had no reliable way of telling who was asking. The API replaces that handoff with a mediated exchange — the site declares which credentials it needs and in which protocol, the browser shows a chooser the site cannot see into, and the wallet receives the request annotated with the origin the browser itself asserts. What matters most here is less the API call than how the wallet establishes who is asking, because that is what decides whether any attribute is released at all.

What the Browser Mediates

A request passes one or more protocol-specific payloads to navigator.credentials.get() under a digital member, each naming an exchange protocol and carrying that protocol's own request object. The API defines no credential format or query language of its own: it carries OpenID for Verifiable Presentations requests in signed, unsigned, and multi-signed variants alongside ISO mdoc for mobile documents, with a matching issuance protocol behind navigator.credentials.create(). Which attributes are requested, and how the response is proved, remains entirely a matter for the protocol inside; the API contributes the channel and the consent step.

The constraints on that channel are where the security value lies. The call requires transient user activation and consumes it, so a page cannot silently probe for wallets, and the response becomes available only after the user has chosen a credential and approved the disclosure. Sites cannot enumerate installed wallets or discover which credentials a user holds, which removes a fingerprinting surface along with the ability to distinguish a user who carries a government credential from one who does not. Requests stay visible to the browser so it can apply risk analysis and abuse mitigation, while responses are encrypted to the verifier. Access is limited to secure contexts and gated per feature by permissions policy, so an embedded third-party frame cannot ask for credentials unless the embedding document delegates that right — the same delegation decision that matters for embedded authentication, and one that is easy to grant more broadly than intended.

Authenticating the Verifier

In a redirect-based presentation flow the wallet learns who is asking from the request itself. This API offers two different answers at once, and choosing between them is an architectural decision rather than a configuration detail.

With an unsigned request, the only claim about the verifier's identity is the origin the browser passes to the wallet. That is genuinely stronger than what custom URL schemes offered — the origin is not attacker-controlled, and a request cannot be replayed as though it came from a different site — but it remains an assertion by the user's own software about the page in front of them. In a cross-device flow, where the request is relayed from a desktop browser to a wallet on a phone, the wallet ends up trusting a channel it did not establish and an origin it cannot check for itself.

With a signed request, the verifier proves its identity cryptographically, and the wallet can evaluate that identity against a trust framework independently of how the request arrived. Regulated ecosystems require exactly this. Under eIDAS 2.0 a wallet must authenticate the relying party before releasing attributes, and relying parties register with a member state, declaring which attributes they intend to request and for what purpose, so that the wallet can warn the user when a request goes beyond what was declared. Registration certificates turn purpose limitation into something enforced at presentation time rather than audited afterwards — the same move from onboarding agreement to verification-time rule that OpenID Federation makes for federation metadata, and the trust registry layer a Self-Sovereign Identity deployment otherwise builds as a bespoke list.

Being a verifier is therefore no longer only an integration task. It means holding and rotating a key, obtaining and keeping an accreditation, and living with a declared purpose that limits what may be asked. That is an identity lifecycle of its own, and it belongs with whoever owns the Decentralized Identifier and signing material behind it rather than with the application team calling the API.

Where It Fits

By making wallet presentation an ordinary web capability, the API changes what is realistic for a relying party to attempt. Attribute-level requests become viable where a full identity check used to be the only option — proving an age threshold, a residency, or a professional qualification without collecting the underlying document — and this is where selective disclosure stops being a property of a credential format and becomes something a verifier can actually consume. It also opens a second path for Identity Proofing: a credential issued once by an accredited party after a proofing process can be presented cryptographically, instead of every relying party repeating document capture and liveness checks. Whether that raises or lowers assurance depends on who issued the credential and how strictly the wallet binds it to its holder, and the API neither answers that question nor tries to.

Two limits are worth stating plainly. The API mediates presentation; it does not federate identity, maintain a session, or authorize anything. A presented credential is evidence at a single moment, so turning it into an authenticated session still calls for OpenID Connect or OAuth 2.1 alongside it, with passkeys remaining the mechanism for recurring authentication rather than a wallet presentation on every visit. And the specification is a Working Draft on the Recommendation track being deployed ahead of its own stabilization: it ships in stable releases of two major browser engines with a third implementing, and its protocol identifiers were folded into the specification itself after an extensible registry was dropped, so which protocols are available is now a browser release question rather than an ecosystem registration one.

Summary

Assess it now if wallet-based credentials are in scope, particularly under a European regulatory timeline, because the slow parts are not the client integration. Decide whether requests will be signed, since only signed requests give the wallet a verifier identity that survives a cross-device relay. Establish who holds and rotates the verifier key. Start relying party registration and the purpose declaration early, because that is an accreditation process rather than a deployment step. And be deliberate about which embedded content receives the permissions policy delegation. The API itself is a small surface, deliberately so: it makes the wallet ecosystem reachable from a web page and leaves the trust decisions where they were always going to sit.