The Digital Credentials API: Browsers Are Building an Age-Verification Layer Nobody Asked to Build
A new W3C API lets sites request a cryptographic age proof from a phone's wallet instead of a photo-ID upload. Here's what it actually reveals — and what it doesn't.
By Palancar · 5 min · 6 October 2026
The Digital Credentials API: Browsers Are Building an Age-Verification Layer Nobody Asked to Build
Age-verification laws have arrived faster than any consistent technical way to comply with them, so the last few years produced the same bad pattern over and over: a site asks a visitor to upload a photo of a government ID to prove they’re an adult, the image sits in some vendor’s storage, and eventually it leaks. A Discord support vendor’s breach in October 2025 exposed roughly 70,000 uploaded ID photos — a plain demonstration of what “store a full ID to answer a yes/no question” actually costs when it goes wrong. Browser vendors have spent 2025 and 2026 shipping a different mechanism, the W3C Digital Credentials API, that is designed specifically so a site never has to see the ID at all. Whether it’s the right layer for browsers to be building is a separate question from whether it’s technically better than the status quo — and it’s worth being precise about both.
What the API Actually Does
The Digital Credentials API lets a website call navigator.credentials.get() and request a specific, narrow claim from whatever credential wallet the user has on their device — Apple Wallet, Google Wallet, or a third-party identity app. The underlying document format is usually an mdoc, standardized in ISO/IEC 18013-5 for the mobile driver’s license use case and extended by ISO/IEC 18013-7 to cover exactly this kind of remote, browser-mediated presentation. The credential is cryptographically signed by the issuing authority (a state DMV, in the mobile-driver’s-license case) and supports selective disclosure: a site can request “is this person over 18” as a single signed boolean and receive nothing else — not a birthdate, not a name, not an address, not a photo. That is the core privacy argument for the API, and it’s a real one: a site that only needed a yes/no answer previously had no standard way to ask for just that, so it defaulted to collecting the entire document.
Where It Stands in the Standards Process
The API is a W3C Working Draft under the Federated Identity Working Group, with the most recent Working Draft published in December 2025. It has not reached Candidate Recommendation, and estimates for when it might are 2026 or 2027 — this is still a moving specification, not a settled one, and sites building against it should expect the request shape and permission model to keep changing.
Where It’s Actually Shipped
Support is inconsistent across browsers and platforms in a way that matters for anyone evaluating “is this ready.” Chrome shipped the API to stable in Chrome 141 in September 2025, but only on Android — Chrome on desktop and iOS does not support it as of this writing. Safari 26, released the same month, shipped support across Apple’s platforms. Firefox has landed baseline implementation code as of early 2026 without a stable, default-on release yet. In practice, today the API mostly works for an Android user with Chrome or an Apple-platform user with a current Safari, and mostly doesn’t for anyone on a desktop browser other than Safari — a real gap for any site trying to use it as a universal replacement for photo-ID upload rather than one option among several.
What It Reveals That an ID Upload Doesn’t — and What It Still Reveals
The honest comparison isn’t “private API versus invasive upload,” it’s more specific than that. A photo-ID upload discloses everything on the document to whatever server receives it, indefinitely, subject to that vendor’s retention and security practices — which is exactly the exposure the Discord-adjacent breach demonstrated. The Digital Credentials API’s selective disclosure model is a genuine improvement on that specific axis: a well-built request asks for the minimum claim and the wallet enforces that only that claim is released.
But the API doesn’t eliminate the metadata problem, it relocates it. The site still learns that the user has a government-issued credential of a specific type, from a specific issuer, presented at a specific time — and the request itself is a new signal a hostile or careless site could over-ask for, requesting full identity fields when a boolean would do, precisely because the API makes it technically easy to ask for more than is needed. The EU’s own Digital Identity Wallet framework, which all member states are required to make available to citizens by December 2026, is explicit that the wallet architecture is meant to enforce minimal disclosure by policy, not just by technical capability — which is a tacit admission that the technical capability alone doesn’t guarantee restraint from the requesting side.
The Adoption Gap Nobody’s Framing Foregrounds
The other honest limitation: this only works for someone who has already provisioned a digital ID into a wallet, and as of mid-2026 most people haven’t. A mobile driver’s license or wallet-based age credential requires a state or national issuer to support it, a user to have gone through an enrollment flow, and a device that supports the wallet — none of which is universal yet. Until that changes, sites adopting age-gating under new laws still need a fallback for the much larger population without a provisioned credential, which means the photo-ID-upload problem this API is meant to retire doesn’t actually go away for years, it just becomes the fallback path rather than the primary one.
For readers evaluating any service that starts asking for age verification: the Digital Credentials API is the right direction on paper, but “supports the Digital Credentials API” and “actually protects your identity data” aren’t the same claim — check what specific claim a site is requesting, not just which mechanism it uses to request it. It’s the same discipline worth applying to any wallet-based credential, passkeys included — our passkey coverage makes a similar case that the browser-support question stopped being the interesting one once the underlying mechanism matured.