The 5 November 2026 Working Draft narrows the spec to three named protocols and drops the open registry model — a small change in the text with real consequences for anyone building a verifier or issuer flow on the web.
The W3C Federated Identity Working Group published a new Digital Credentials Working Draft on 5 November 2026, the first update since the open protocol registry was retired at TPAC last November. The current text fixes the spec to exactly three supported protocols — OpenID4VP, OpenID4VCI, and ISO 18013-7 Annex C — instead of letting implementers register arbitrary new ones. Coverage from ID Tech Wire frames the move the same way: less flexibility for protocol designers, more predictability for the sites and native apps that actually have to request and present a credential. For teams wiring identity verification into a product, that predictability is the difference between a feature you can ship once and one you have to re-test every time a browser updates its implementation — the same reliability bar that applies to any Android app development work that has to talk to the OS credential layer.
The Digital Credentials API lets a web page call navigator.credentials.get() with a digital mediation type and ask the operating system's credential layer — not the page itself, not a third-party script — to collect a specific credential from whichever wallet app the user has on the device. The browser never sees the raw credential; it brokers a request and hands back a signed response. Before this draft, the spec allowed any party to register a new exchange protocol into an open list, which is flexible but makes conformance testing and cross-browser behavior hard to pin down. The 5 November text removes that openness in favor of three named protocols: OpenID4VP and OpenID4VCI for presenting and issuing verifiable credentials over OpenID-style flows, and ISO 18013-7 Annex C for mobile driving licenses specifically. Anything outside those three is out of scope for this version of the spec.
Browser support already exists — Chrome and Safari shipped stable Digital Credentials API support in 2025, and Firefox has baseline implementation code even though it hasn't shipped it yet. What was missing was a stable contract for what a conforming implementation has to support, and that's exactly what narrowing the protocol list buys the ecosystem. For a site that wants to let a user prove their age, present a verified-identity credential, or pull a digital driving license into a checkout flow, the web side of the handshake is now spec-stable. The part that still requires real engineering is everything upstream of the browser call: the OS has to have a credential provider registered and ready to answer that request, and on Android that provider relationship runs through the platform's Credential Manager APIs — a native integration surface, not a web one. A product that wants its own wallet or ID app to answer these requests on Android devices needs that native plumbing built and tested against the same three protocols the W3C just locked in, which is squarely native Android development work layered underneath a standards-compliant web flow.
navigator.credentials.get() with digital mediation) is stable enough to build against now — test it in Chrome and Safari, where it already ships.This is a Working Draft, not a Recommendation — the document itself is still open to change, and the W3C explicitly calls it a draft on the Recommendation track rather than a finished spec. The protocol-list narrowing it codifies, however, reflects a decision already made at TPAC in November 2025, so implementers shouldn't expect that part to be reopened. Browser support is live today in Chrome and Safari; treat the three-protocol list as the stable target to build against, and watch the W3C's working draft index for the next revision rather than expecting a sudden Recommendation-track jump.