--- url: 'https://www.corbado.com/blog/digital-credentials-api' title: 'Digital Credentials API (2026): Chrome, Safari & Firefox' description: 'Learn about the Digital Credentials API, its support in Chrome, Safari & Firefox and stay up-to-date on protocol changes, issuance, and the EU mandate.' lang: 'en' author: 'Vincent Delitz' date: '2025-05-11T14:57:56.639Z' lastModified: '2026-03-28T07:00:57.542Z' keywords: 'digital credentials api, dc api, digital credentials' category: 'Engineering' --- # Digital Credentials API (2026): Chrome, Safari & Firefox ### Digital Credentials API: Browser Support Snapshot (March 2026) _Last updated: March 26, 2026_ A quick overview of Digital Credentials API support in major browsers: | Browser | Support Status (March 2026) | Stable Release / Outlook | | :-------------- | :---------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Google Chrome | ✅ **Shipped (Stable)** — protocol-agnostic (OpenID4VP **and** ISO 18013-7 Annex C) | **Chrome 141** ([Stable since **Sept 30, 2025**](https://developer.chrome.com/blog/digital-credentials-api-shipped)); desktop cross-device via CTAP/BLE. [See §6.1](#61-google-chrome-shipped) | | Apple Safari | ✅ **Shipped (Stable)** — **mdoc-only** via `org-iso-mdoc` | **Safari 26** ([released **Sept 15, 2025**](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/)); supports Wallet & registered document provider apps. [See §6.2](#62-apple-safari-mdoc-focus) | | Mozilla Firefox | 🔧 **In Development** — baseline landed in Firefox 149 | Formal [negative standards position](https://github.com/mozilla/standards-positions/issues/1003) unchanged, but [active implementation underway](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). [See §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | Microsoft Edge | ✅ **Shipped (Stable)** — Chromium-based, follows Chrome 141 | **Edge 141** (Stable early Oct 2025); inherits Chromium 141 capabilities. | ## Timeline: What's the Status of Digital Credentials? The world of digital credentials is moving fast. Here's a snapshot of key developments and projections: | **Icon** | **Date / Period** | **Event** | **Description & Source** | | :------- | :-------------------------- | :------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 🚀🤖 | August 20, 2024 | Android Digital Credentials API Origin Trial | [Chrome 128 launches an Origin Trial for the Digital Credentials API on Android](https://developer.chrome.com/release-notes/128), enabling requests via Android's IdentityCredential CredMan system. | | 🚀🍏 | Feb 27, 2025 | Safari Technology Preview 214 | WebKit (included in [Safari Technology Preview 214](https://www.webkit.org/blog/16512/release-notes-for-safari-technology-preview-214/)) adds Digital Credentials API Feature Flag. ([Pull Request](https://github.com/WebKit/WebKit/pull/40008), [Comparison](https://github.com/WebKit/WebKit/compare/c968abdda41af3ad0abbf5c5c2c1fe0d5bb1c016...837aec74d9c8ea88f094c9de12a0a3c936735634)) | | 🚀🤖 | March 4, 2025 | Chrome 134 Desktop Origin Trial | [Chrome 134 launches a Desktop Origin Trial for the Digital Credentials API](https://developer.chrome.com/origintrials/#/view_trial/3981410680008146945), enabling secure communication with Android phone wallets. (Source: Chrome 134 Release Notes) | | 🚀🍏 | Mar 31, 2025 | Safari 18.4 Release | [WebKit Features in Safari 18.4](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) makes parts of the Digital Credentials API testable via a Feature Flag. Ongoing changes tracked [here](https://bugs.webkit.org/buglist.cgi?quicksearch=Digital%20Credentials). | | 💡 | April 2025 | W3C FedID WG Takes Helm | Digital Credentials API development formally moves to the [W3C Federated Identity Working Group](https://github.com/w3c-fedid/digital-credentials). | | 🚀🤖 | April 30, 2025 | Chrome Cross-Device OT Announced | Chrome announces an [Origin Trial for Cross-Device Digital Credentials API](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) starting in Chrome 136, allowing desktop Chrome to securely present credentials from Android devices. | | ⚠️🤖 | May 2, 2025 | Chrome API Breaking Changes | Chrome outlines breaking changes for API versions in Chrome 136 & 138 (e.g., request formats, `navigator.credentials.create()` API added under flag). | | 🚀🍏 | June 10, 2025 | WWDC25: Apple Confirms API Support | Apple officially announces Digital Credentials API support in Safari at WWDC25, confirming a focus on the `org.iso.mdoc` protocol for presenting identity documents. The feature is available in Safari 26 Beta with iOS 26. (Source: [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/)) | | 🧭 | Sept 15, 2025 | Safari 26 Release | [Safari/iOS 26 ships Digital Credentials API](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) with **`org-iso-mdoc`** (mdoc Annex C). | | 🚀🤖 | Sept 30, 2025 | Chrome 141 Stable | [Digital Credentials API ships **stable** in Chrome 141](https://developer.chrome.com/blog/digital-credentials-api-shipped) (Android + desktop cross-device). | | 📣 | Oct 3, 2025 | Launch Blogs | [Chrome](https://developer.chrome.com/blog/digital-credentials-api-shipped) and [WebKit](https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api/) publish shipping posts; Chrome emphasizes **protocol-agnostic** support (OpenID4VP **and** ISO 18013-7 Annex C); WebKit details Safari's **mdoc-only** model and CTAP cross-device flows. | | ⚙️ | Nov 14, 2025 | TPAC: Protocol Registry Eliminated | W3C FedID WG [reaches consensus](https://github.com/w3c-fedid/digital-credentials/issues/396) to drop the open protocol registry and **hardcode supported protocols** (OpenID4VP, OpenID4VCI, ISO 18013-7 Annex C) directly in the spec. Implemented in [PR #401](https://github.com/w3c-fedid/digital-credentials/pull/401) (merged Jan 28, 2026). [See §5](#5-underlying-protocols) | | 🦊 | _Q1 2026_ | Firefox Begins DC API Implementation | Mozilla lands [baseline DC API support](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) in **Firefox 149**, despite unchanged [negative standards position](https://github.com/mozilla/standards-positions/issues/1003). [Implementation source code](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) in mozilla-central. [See §6.3](#63-mozilla-firefox-from-negative-stance-to-active-implementation) | | 🇺🇸 | Feb 27, 2026 | California DMV Adds DC API | California DMV's [OpenCred platform adds DC API support](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) in v10.0.0, becoming an early government adopter of browser-mediated credential presentation. | | 🚀🤖 | _Q1 2026_ | Chrome 143 Issuance Origin Trial | Chrome launches an [Origin Trial for credential **issuance**](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()` with OpenID4VCI, expanding the API beyond presentation. [See §4](#4-how-does-the-digital-credentials-api-work) | | 🇪🇺📅 | _End of 2026 (Anticipated)_ | EUDI Wallets Availability | EU Member States projected to make EUDI Wallets available per [eIDAS 2.0](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng). The EU's [ARF Topic F](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) conditionally requires DC API support for all member state wallets. [See §5.4](#54-eu-digital-identity-wallet-support) | **What Changed Since October 2025?** - **Protocol governance shift**: The W3C FedID WG [eliminated the open protocol registry](https://github.com/w3c-fedid/digital-credentials/issues/396) at TPAC (Nov 2025) and now [hardcodes supported protocols](https://github.com/w3c-fedid/digital-credentials/pull/401) directly in the spec: OpenID4VP, OpenID4VCI, and [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) Annex C. The API is no longer a "dumb pipe." - **Issuance arriving**: Chrome 143 launched an [Origin Trial for credential issuance](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()`, expanding the API beyond presentation-only. - **Firefox implementing**: Despite an unchanged [negative standards position](https://github.com/mozilla/standards-positions/issues/1003), Mozilla [landed baseline DC API code](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) in Firefox 149 with UX work ongoing. - **EU conditional mandate**: The EUDI [Architecture Reference Framework (Topic F)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) now conditionally requires DC API support for all member state wallets. - **Real-world adoption**: [California DMV](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) added DC API support to its OpenCred platform (Feb 2026). ## Key Facts - **Chrome 141** and **Safari 26** shipped stable Digital Credentials API support in September 2025; Firefox 149 carries baseline implementation code as of Q1 2026. - **Safari 26** supports only `org-iso-mdoc`; Chrome 141 supports OpenID4VP and ISO 18013-7 Annex C, requiring relying parties to build dual-protocol backends. - The **W3C FedID WG** eliminated the open protocol registry at TPAC (November 2025), hardcoding OpenID4VP, OpenID4VCI and ISO 18013-7 Annex C directly in the spec. - **EUDI ARF Topic F** conditionally requires DC API support for all member state wallets, contingent on the spec reaching W3C Recommendation status. - Despite a formal **negative standards position**, Mozilla landed baseline DC API code in Firefox 149 in Q1 2026, signaling likely three-browser coverage ahead. ## 1. Introduction: Digital Credentials API Digital credentials are a hot topic in the identity space at the moment. As our lives become increasingly connected with the digital realm, the need for secure, user-centric, and privacy-preserving ways to assert our identity and qualifications online has never been more critical. Traditional methods are showing their age, and the demand for more robust solutions is palpable. In this article, we aim to discuss the current state of the Digital Credentials API, a important development that promises to reshape how we interact with identity information on the web. We will explore its underlying mechanisms, the protocols it supports, current browser adoption, and offer recommendations for both relying parties and [wallet](https://www.corbado.com/blog/digital-wallet-assurance) [issuers](https://www.corbado.com/glossary/issuer) navigating this fast-evolving landscape. ## 2. Digital Identity & Verification Proving identity reliably and securely has been a persistent challenge in the web's architecture for many [years](https://www.finextra.com/blogposting/27820/the-evolution-of-identity-verification-and-whats-next). While the internet facilitated unprecedented connectivity and information exchange, it also opened new avenues for misrepresentation and fraud. In some countries, solutions emerged, primarily driven by early bank consortiums that developed services to leverage existing trusted relationships for online identification. [Governments](https://www.corbado.com/passkeys-for-public-sector) also stepped in, enforcing or providing national [digital identity](https://www.corbado.com/blog/digital-identity-guide) [wallets](https://www.corbado.com/blog/digital-wallet-assurance) and services. However, these solutions were often siloed, geographically limited, and not universally interoperable. The fallback for [identity verification](https://www.corbado.com/blog/digital-identity-guide) in many regions has traditionally involved high-friction processes. Physical verification at a post office, for instance, introduces significant delays and inconvenience. Video calls combined with document uploads became a more digital alternative, followed by the more recent rise of automated document scanning and [liveness checks](https://www.identity.com/the-identity-verification-process-comprehensive-guide/). Despite their advancements, these methods have significant drawbacks. They can be time-consuming, prone to human error or bias, and have been frequently exposed as vulnerable to sophisticated forgery. The challenge is escalating dramatically with the advent of deepfakes, advanced AI-driven impersonation techniques, and increasingly [sophisticated phishing attacks](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). These technologies can create highly realistic but entirely fabricated video, audio, and document evidence, making it incredibly difficult for traditional systems, and even AI-powered verification tools, to distinguish genuine users from fraudulent ones. The potential for creating synthetic identities or manipulating biometric data to bypass checks is a severe threat, particularly for financial institutions and any service requiring robust Know Your Customer (KYC) [processes](https://www.identity.com/the-growing-threat-of-deepfakes-to-identity-verification-processes/). This escalating threat landscape underscores the urgent need for more secure, cryptographically verifiable online identity and verification mechanisms. ## 3. How Do Digital Credentials Work? Understanding how digital credentials operate involves looking at the key players involved and the different technological layers that enable their functionality. ### 3.1. The Three-Party Model At its core, the concept of digital credentials, especially in the context of the new web APIs, revolves around a three-party model: 1. **Issuer**: An entity (e.g., [government](https://www.corbado.com/passkeys-for-public-sector), university, employer) that is authoritative for certain information about a subject and can issue a digital credential attesting to that information. 2. **Holder**: The subject of the information (i.e., the user) who receives the credential from the [issuer](https://www.corbado.com/glossary/issuer) and stores it in a [digital wallet](https://www.corbado.com/blog/digital-wallet-assurance). The holder controls when and what information from the credential is shared. 3. **Verifier** (or [Relying Party](https://www.corbado.com/glossary/relying-party)): An entity (e.g., a website, an online service) that needs to verify certain information about the holder to grant access to a service or resource. The verifier requests the necessary information from the holder. ![three party model](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/three_party_model_5eedaec078.png) This three-party model is important because it aims to put the user (holder) in control of their own data. Unlike traditional identity systems where data might be centrally stored or shared between parties without direct user intermediation, this model emphasizes user consent and selective disclosure. The holder decides which pieces of information to share from a credential for a specific transaction, rather than revealing the entire credential. A fundamental aspect of these systems is the involvement of cryptographic key pairs. The [issuer](https://www.corbado.com/glossary/issuer) digitally signs the credential, ensuring its authenticity and integrity. The holder, in turn, uses their private key, often secured within their [digital wallet](https://www.corbado.com/blog/digital-wallet-assurance) (which is protected by device hardware), to prove control over the credential and to authorize its presentation to a verifier. This typically involves the verifier presenting a challenge (a random piece of data) which the holder's [wallet](https://www.corbado.com/blog/digital-wallet-assurance) signs using the private key associated with the credential. The verifier can then use the corresponding public key to confirm the signature, thus authenticating the presentation. This explanation is protocol-neutral, as the core principles of issuance, holding, and verification through cryptographic challenges are common across different underlying technologies. This article concentrates on the **verification** of digital credentials and the principle of **selective disclosure**, enabling users to prove specific attributes (e.g., "I am over 18," "I possess a valid driver's license") without revealing the entire source document. While the underlying systems for digital credentials may support features like Qualified Electronic Signatures (QES) and remote signing capabilities (as seen in comprehensive solutions like the EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide) [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) for legally binding signatures), the focus here, particularly for the Digital Credentials API, is on identity [assertion](https://www.corbado.com/glossary/assertion) and attribute verification for online interactions, not primarily on these broader signing functionalities. ### 3.2. Layers of Digital Credentials To understand how digital credentials function, it's helpful to visualize a layered model. Each layer addresses a different aspect of the ecosystem, from the data format itself to how it's presented to a user in a web browser. This article primarily focuses on the **Digital Credentials API**, which operates at the presentation layer. ![Digital credential layers ](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_26eaf37952.png) **Core Terminology:** - **Digital credential:** Any machine-readable credential (PDF with a barcode, ISO [mDL](https://www.corbado.com/blog/mobile-drivers-license), W3C VC, SD-JWT, etc.). "Digital" says nothing about cryptographic verifiability. - **Verifiable Credential:** A kind of digital credential, defined by the W3C VC Data Model. It adds tamper-evidence and cryptographic proof, and it always lives in a three-party world: [issuer](https://www.corbado.com/glossary/issuer) → holder → verifier. - **[Verifiable Credential API](https://w3c-ccg.github.io/vc-api/):** A REST/HTTP service interface for issuing, storing, presenting and verifying VCs between back-end systems (issuers, [wallets](https://www.corbado.com/blog/digital-wallet-assurance), verifiers). - **[Digital Credentials API (DC API)](https://github.com/w3c-fedid/digital-credentials):** A browser / operating-system API (JavaScript + native plumbing) that lets a web site ask the user's device-side wallet to present any supported digital credential (VC, ISO [mDoc](https://www.corbado.com/glossary/mdoc), SD-JWT …) in a privacy-respecting way. Think of VCs as a data model, VC API as a back-end spec, and DC API as the front-end implementation that presents credentials to the Web. Everything above layer 1 (Data-model layer) is format-agnostic; everything below depends on the credential format. **End-to-end flow (example: online age verification):** The following diagram illustrates how these layers work together in a real-world scenario. Notice how the data is a VC, the transport on the Web is DC API, the exchange protocol underneath is [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), and the server-side check uses VC API. **Why the split exists:** - **Interoperable data model (cryptographic proofs, selective disclosure):** Solved by VC Data Model (& other formats). - **Standard REST endpoints for back-end systems:** Solved by VC API. - **Wallet ↔ Web-site handshake that's privacy-preserving:** Solved by DC API. - **Different trust levels / document types (government ID vs. course certificate):** Solved by Using the right format (ISO [mDoc](https://www.corbado.com/glossary/mdoc) for high-assurance IDs; W3C VC for general claims) underneath DC API. **Key take-aways:** 1. "Digital credential" is the umbrella term. 2. [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) is a kind of digital credential with built-in cryptographic verifiability. 3. VC API is server-to-server plumbing for life-cycle operations on VCs. 4. Digital Credentials API is the browser-to-wallet bridge that finally lets those credentials flow smoothly into Web-apps, whatever concrete format they're in. 5. The three pieces are complementary, not competing—they sit at different layers of the same stack and together enable secure, user-centric identity on the open Web. Having explored the participants and the overall layered architecture of digital credentials, this article will now go deeper into the presentation layer, specifically focusing on the Digital Credentials API and its current state. ## 4. How Does the Digital Credentials API Work? As the crucial component at the presentation layer, the Digital Credentials API is a web standard currently being developed to provide a secure and standardized way for websites to request and receive [digital identity](https://www.corbado.com/blog/digital-identity-guide) information from users' digital [wallets](https://www.corbado.com/blog/digital-wallet-assurance). This effort is primarily housed within the W3C's Federated Identity Working Group (FedID WG), having migrated from the FedID Community Group in April 2025. The official draft specification can be found here: [https://w3c-fedid.github.io/digital-credentials/](https://w3c-fedid.github.io/digital-credentials/). As of October 2025, the API has **shipped in stable versions** of both Chrome 141 (Sept 30, 2025) and Safari 26 (Sept 15, 2025). Chrome's implementation supports both [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) and [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) Annex C, while Safari exclusively supports the `org-iso-mdoc` protocol. **Important (March 2026 update):** The API's relationship with protocols has changed fundamentally. At TPAC in November 2025, the W3C FedID WG [reached consensus](https://github.com/w3c-fedid/digital-credentials/issues/396) to **eliminate the open protocol registry** and instead [hardcode a finite list of supported protocols](https://github.com/w3c-fedid/digital-credentials/pull/401) directly in the spec: `openid4vp-v1-unsigned`, `openid4vp-v1-signed`, `openid4vp-v1-multisigned`, `org-iso-mdoc` (for presentation), and `openid4vci-v1` (for issuance). User agents are expected to reject unlisted protocols. This makes the Working Group a de facto gatekeeper for future protocol additions — a deliberate tradeoff to enable holistic security and privacy review of everything that flows through the API (see the [current Working Draft](https://www.w3.org/TR/digital-credentials/)). The spec also now covers **credential issuance** via `navigator.credentials.create()`. Chrome 143 launched an [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) for this, allowing websites to trigger wallet provisioning flows using OpenID4VCI. However, a [wallet selection binding vulnerability](https://github.com/w3c-fedid/digital-credentials/issues/382) — where a malicious wallet app can intercept issuance pre-authorization codes — remains an open concern. Government issuers have indicated they will not adopt browser-mediated issuance until this is resolved. Chrome supports presentation natively on [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) through its [Credential Manager system](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html) and also supports [Cross-Device Digital Credentials API](https://developer.chrome.com/blog/digital-credentials-cross-device-ot) on desktop via CTAP/BLE-backed QR handoff. The API extends the existing [Credential Management API](https://www.w3.org/TR/credential-management-1/) by enabling requests for digital credentials through `navigator.credentials.get()`. According to the W3C FedID WG Digital Credentials Explainer ([https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md)), the API has reverted to using this established interface rather than the previously proposed `navigator.identity`. A website requests a digital credential by calling `navigator.credentials.get()` with specific parameters for digital credentials. Here's an illustrative example of how a website might call the API to request a credential using the [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp): ```javascript async function requestCredential() { // Check for Digital Credentials API support if (typeof window.DigitalCredential !== "undefined") { try { // These parameters are typically fetched from the backend. // Statically defined here for protocol extensibility illustration purposes. const oid4vp = { protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125 data: { nonce: "n-0S6_WzA2Mj", presentation_definition: { //Presentation Exchange request, omitted for brevity }, }, }; // create an Abort Controller const controller = new AbortController(); // Call the Digital Credentials API using the presentation request from the backend let dcResponse = await navigator.credentials.get({ signal: controller.signal, mediation: "required", digital: { requests: [oid4vp], }, }); // Send the encrypted response to the backend for decryption and verification // Ommitted for brevity } catch (error) { console.error("Error:", error); } } else { // fallback scenario, illustrative only alert("The Digital Credentials API is not supported in this browser."); } } ``` This example is taken from [here](https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md). The Digital Credentials API essentially acts as a secure wrapper or intermediary. It allows the browser to mediate the request for identity information, leveraging the underlying operating system's capabilities to discover available wallets and credentials that match the [request](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). The browser and OS can then present a consistent user interface for selecting the credential and authorizing its release, enhancing security and privacy by ensuring user consent and preventing websites from silently accessing sensitive [data](https://w3c-fedid.github.io/digital-credentials/). The actual credential data in the response is intended to be opaque (encrypted) to the browser itself, with decryption and interpretation handled by the [relying party](https://www.corbado.com/glossary/relying-party) and the wallet/[holder](https://w3c-fedid.github.io/digital-credentials/). ## 5. Underlying Protocols The Digital Credentials API was originally designed to be fully protocol-agnostic, acting as a "dumb pipe" with an open registry for any protocol to register. However, as of January 2026, the spec [now explicitly names](https://github.com/w3c-fedid/digital-credentials/pull/401) the protocols it supports — user agents are expected to reject unlisted ones. The two main families of protocols currently hardcoded in the spec are: org.iso.[mdoc](https://www.corbado.com/glossary/mdoc) (derived from [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) and its extension [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) "Annex C") and the OpenID Foundation's OpenID for Verifiable Presentations (OpenID4VP) and OpenID for [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) Issuance (OpenID4VCI) specifications. ### 5.1. org.iso.mdoc - **Origin and Standardization**: org.iso.mdoc refers to the data format and interaction model for mobile documents, primarily mobile Driving Licenses (mDLs), standardized by the International Organization for Standardization (ISO) and the International Electrotechnical (IEC). The foundational standard is [ISO/IEC 18013-5](https://www.iso.org/standard/69084.html), which defines the [mDL](https://www.corbado.com/blog/mobile-drivers-license) application, data structure, and protocols for in-person (proximity) presentation using technologies like NFC, Bluetooth, or QR [codes](https://sphericalcowconsulting.com/2024/01/03/verifiable-credentials-and-mdocs-a-tale-of-two-protocols/). [ISO/IEC 18013-7](https://www.iso.org/standard/82772.html) extends this to enable online/remote presentation of [mDLs](https://www.corbado.com/blog/mobile-drivers-license). The protocol string "org.iso.mdoc" is specifically defined in ISO/IEC TS 18013-7 (Annex C) for use with APIs like the Digital Credentials API. - **Data Model**: [mdocs](https://www.corbado.com/glossary/mdoc) have a strictly defined data structure based on [CBOR](https://www.corbado.com/glossary/cbor) (Concise Binary Object Representation) for compactness and efficiency. It specifies namespaces and data elements for common driving license attributes and supports strong cryptographic security features, including issuer authentication, device binding, holder authentication (via portrait), session encryption, and selective disclosure. - **Typical Use Cases**: Primarily [government](https://www.corbado.com/passkeys-for-public-sector)-issued identity documents like driver's licenses and national IDs. It's designed for high-assurance scenarios, both in-person (e.g., traffic stops, age verification for restricted goods) and online (e.g., accessing [government](https://www.corbado.com/passkeys-for-public-sector) services, remote [identity verification](https://www.corbado.com/blog/digital-identity-guide) for bank [account opening](https://www.corbado.com/blog/digital-identity-verification)). ### 5.2. OpenID4VP and OpenID4VCI - **Origin and Standardization**: OpenID4VP (for presentation) and [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) (for issuance) are specifications developed by the OpenID Foundation. They extend [OAuth 2.0](https://www.corbado.com/glossary/oauth2) to support the exchange of [verifiable credentials](https://www.corbado.com/glossary/microcredentials). These are open standards aimed at broad interoperability for various credential types, not just government. As of early 2025, OpenID4VP is in advanced draft stages (e.g., draft 28 as of April). [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) is also maturing. - **Data Model**: OpenID4VP/VCI are designed to be credential format-agnostic. They can carry W3C [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (VCs) in JSON/[JSON-LD](https://www.corbado.com/glossary/json-ld) or JWT formats, [mdocs](https://www.corbado.com/glossary/mdoc), SD-JWTs, and other formats. The interaction model involves an Authorization Request from the Verifier (RP) and a response from the Holder's Wallet containing a vp_token (Verifiable Presentation Token. Selective disclosure is typically managed using query languages like Presentation Exchange (DIF PE) or the newer Digital Credentials Query Language DCQL. - **Typical Use Cases**: Broad range of applications, including [identity verification](https://www.corbado.com/blog/digital-identity-guide), providing proof of qualifications (e.g., educational diplomas, professional certifications), membership [attestations](https://www.corbado.com/glossary/attestation), and more. They are well-suited for online interactions where a [relying party](https://www.corbado.com/glossary/relying-party) needs to verify claims from various [issuers](https://www.corbado.com/glossary/issuer). ### 5.3. Comparison of org.iso.mdoc and OpenID4VP/VCI | Feature | org.iso.mdoc (ISO 18013-5/7) | OpenID4VP / OpenID4VCI | | :----------------------- | :----------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------ | | **Standardizing Body** | ISO/IEC | OpenID Foundation | | **Primary Focus** | Mobile Driver's Licenses (mDLs) & official IDs | General verifiable credential exchange (any type) | | **Data Format** | CBOR-based, strictly defined data elements | Agnostic; commonly [W3C VCs](https://www.w3.org/TR/vc-data-model-2.0/) (JSON/JWT), mdocs, SD-JWTs | | **Transport** | Defined for proximity (NFC, BLE, QR) & online (18013-7) | Primarily OAuth 2.0-based for online; can be initiated via QR, deep links | | **Selective Disclosure** | Built-in via salted hashed claims | Via query languages like Presentation Exchange or DCQL | | **Maturity** | ISO 18013-5: Published Standard. ISO 18013-7: Published TS. ISO 23220 series (general mDocs): In development | OpenID4VP: Advanced Draft (e.g., draft 28, April 2025). OpenID4VCI: Advanced Draft | | **Typical Issuers** | Government agencies (DMVs, etc.) | Governments, educational institutions, employers, any entity | | **Cost of Standard** | Paid | Free / Open | It's important to recognize that these are not always mutually exclusive. OpenID4VP can, for example, be used to request and transport an \[org.iso.mdoc]. The choice often depends on the specific use case, the type of credential, and the ecosystem participants. ### 5.4. EU Digital Identity Wallet Support The European Union Digital Identity (EUDI) Wallet is a major initiative aiming to provide all EU citizens and residents with a secure [digital wallet](https://www.corbado.com/blog/digital-wallet-assurance) for identity documents and [attestations](https://www.corbado.com/glossary/attestation). The EUDI Wallet architecture and reference framework explicitly plan to support both mdoc (particularly for Mobile Driving Licenses) and W3C [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials), utilizing OpenID4VP and [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) for presentation and issuance flows. The reference implementation includes support for OpenID4VP transferring [mDocs](https://www.corbado.com/glossary/mdoc) and OpenID4VCI for issuing PIDs and [mDLs](https://www.corbado.com/blog/mobile-drivers-license) in mDoc and SD-JWT-VC [formats](https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md). This dual support by such a [large-scale](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) project underscores the importance of both protocol families. **March 2026 update:** The EU's commitment to the Digital Credentials API has become more concrete. The EUDI [Architecture Reference Framework (ARF) Topic F](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) now **conditionally requires** that EUDI Wallet Units and Relying Parties support the DC API for remote presentation and [attestation](https://www.corbado.com/glossary/attestation) issuance flows. The conditions include the DC API reaching W3C Recommendation status and meeting expectations around functionality, browser/OS neutrality, privacy, and denial-of-service protection. The [European Wallet Consortium (EWC)](https://eudiwalletconsortium.org/) has incorporated DC API test cases into its conformance testing program, and the [NOBID consortium](https://www.nobidconsortium.com/) completed [payment](https://www.corbado.com/passkeys-for-payment) pilots using OpenID4VP — the same protocol that DC API now carries. However, this direction is not without criticism, as some observers note that the Digital Credentials API, heavily influenced by "US Bigtech" companies, might become deeply incorporated into the final EUDI Wallet specifications. Concerns have been raised about the potential influence of non-EU entities on a critical piece of EU infrastructure, as discussed in community forums such as [this GitHub discussion](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/361). Separately, the decision to [hardcode the ISO 18013-7 reference](https://github.com/w3c-fedid/digital-credentials/pull/401) in the spec has drawn an [objection from Ping Identity](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228), arguing that normatively referencing a paywalled specification conflicts with open web principles — a concern that could surface as a formal objection when the spec transitions to Candidate Recommendation. ## 6. Which Browser supports the Digital Credential API? The browser landscape for the Digital Credentials API has now taken shape, with **Chrome 141** and **Safari 26** shipping stable support in September 2025. There are notable differences in approach and support levels across browsers. ### 6.1. Google Chrome: Shipped in 141; Protocol-Agnostic Chrome **shipped** the Digital Credentials API in **Chrome 141** (Sept 30, 2025). Chrome's implementation is **protocol-agnostic**: compatible with **OpenID4VP** and **ISO 18013-7 Annex C** (mdoc online). Desktop supports **cross-device** presentation from mobile wallets via a **CTAP/BLE-backed** channel (QR handoff), with the response opaque to the browser. The API shape moved to `navigator.credentials.get()`; **parameters renamed**: `providers` → `requests`, `request` → `data`. **Feature Detection:** ```javascript if (typeof DigitalCredential !== "undefined") { // Digital Credentials API supported } ``` [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Manager natively supports OpenID4VP for presentation and OpenID4VCI for [issuance](https://www.androidcentral.com/apps-software/android-os/google-enhances-digital-credentials-access-with-androids-open-standards-support), allowing [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) apps to act as credential holders and verifiers using these [standards](https://android-developers.googleblog.com/2025/04/announcing-android-support-of-digital-credentials.html). Google notes growing wallet support; **Google Wallet** is an early adopter, with **Samsung Wallet** and **1Password** announced. ### 6.2. Apple Safari: Shipped in 26; mdoc-only (`org-iso-mdoc`) In previous versions of this article, we predicted that Apple's approach would diverge from Google's by focusing on the `org.iso.mdoc` protocol. For historical context, our reasoning was as follows: > Evidence from WebKit bug trackers and standards contributions suggested that Safari > would opt to **focus support on `org.iso.mdoc`** directly, rather than prioritizing > OpenID4VP as the transport layer for all credential types. This was likely driven by > technical reservations about [OpenID4VP's](https://www.corbado.com/glossary/open-id-4-vp) complexity in a > browser context and Apple's deep investment in shaping the ISO mdoc standards to align > with their platform's security model. As we correctly anticipated, [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) confirmed this strategy. Safari **26** (iOS/iPadOS/macOS) **shipped** on Sept 15, 2025 with Digital Credentials API support, confirming that their implementation **exclusively supports the `org-iso-mdoc` protocol** (hyphenated) for presentation. This was detailed in the [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) session [Verify identity documents on the web](https://developer.apple.com/videos/play/wwdc2025/232/). The API allows websites to request verifiable information from identity documents, such as a driver's license, stored in Apple Wallet or in third-party document provider apps. Key takeaways from Apple's implementation: - **MDOC-Only**: The API exclusively uses the protocol string `"org-iso-mdoc"`, based on the ISO/IEC 18013-7 Annex C standard. There is **no support for OpenID4VP** in Safari's implementation of the Digital Credentials API. - **Presentation Only**: The API is for presentation (verification) of existing credentials. Issuance into Apple Wallet or other apps remains a separate, non-browser process. - **User-Centric & Secure**: The flow is initiated by a user gesture and leverages a "partial request" mechanism, where the OS first parses and validates the request in a sandbox before passing it to the wallet application, enhancing security. - **Extensible to Apps**: In addition to Apple Wallet, third-party apps can act as document providers by implementing the new `IdentityDocumentServices` framework and an app extension. - **Cross-Device Support**: **Cross-device** presentation from non-Apple platforms uses CTAP for proximity after a [QR code](https://www.corbado.com/blog/qr-code-login-authentication) handoff; the JS response remains encrypted/opaque to the browser. Apple provided a clear code example for how a relying party would use the API: ```javascript async function verifyIdentity() { try { // Server generates and cryptographically signs the request data. const response = await fetch("drivers/license/data"); const data = await response.json(); // The request specifies the 'org-iso-mdoc' protocol. const request = { protocol: "org-iso-mdoc", // data contains the cryptographically signed mdoc request. data, }; // The API must be called from within a user gesture. const credential = await navigator.credentials.get({ mediation: "required", digital: { requests: [request], }, }); // Send the encrypted response from the wallet to the server for decryption and validation. const verificationResponse = await fetch("/decrypt", { method: "POST", body: JSON.stringify(credential.data), headers: { "Content-Type": "application/json", }, }); // Display the verified details... const json = await verificationResponse.json(); presentDetails(json); } catch (err) { // Handle errors, e.g., user cancellation. } } ``` This confirmation solidifies the divergent strategies in the browser market. While Chrome builds on the flexible OpenID4VP transport layer, Apple is leveraging its deep investment in the ISO mdoc ecosystem to provide a highly integrated and secure, albeit less flexible, solution tailored to official identity documents. ### 6.3. Mozilla Firefox: From Negative Stance to Active Implementation Mozilla originally expressed a **negative standards position** on the Digital Credentials API. Their concerns, [documented in detail](https://github.com/mozilla/standards-positions/issues/1003), are comprehensive and rooted in their mission to protect [user privacy](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys), agency, and ensure an open, equitable web. Key concerns raised by Mozilla include: - **Privacy Risks**: Potential for increased sharing of personal data and a reduction in online anonymity if requests for digital credentials become commonplace for trivial interactions. - **User Exclusion**: Risk that individuals who cannot or choose not to use digital credentials could be excluded from online services and communities. Government-issued credentials, a primary use case, may not align with an individual's choice of identity presentation. - **Interoperability Problems**: Concerns about a proliferation of credential formats leading to a fragmented ecosystem rather than a universally interoperable one. - **Selective Disclosure**: Worries that the privacy benefits of selective disclosure could be undermined if not implemented with strong unlinkability guarantees, or if users do not fully understand what is being shared. - **Centralization of Trust and User Agency**: Fears that the API could lead to increased centralization of trust and a reduction in user agency, perpetuating existing societal power imbalances. While a [W3C Council overruled a formal objection](https://www.w3.org/2025/02/council-report-fedid-dig-cred.html) related to these concerns (to allow the work to proceed within W3C rather than potentially less transparent venues), the Council did recommend that the Working Group actively work to mitigate these potential harms. **March 2026 update — Implementation underway:** Despite the formal negative position remaining [technically unchanged](https://github.com/mozilla/standards-positions/issues/1003), Mozilla has begun **actively implementing** the Digital Credentials API. In Q1 2026, [baseline DC API support](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077) landed in **Firefox 149** (behind a preference flag), tracked under [meta bug 2004828](https://bugzilla.mozilla.org/show_bug.cgi?id=2004828). The [source code](https://searchfox.org/mozilla-central/source/dom/credentialmanagement/digital/) is in mozilla-central, including `DigitalCredential.cpp`, WebIDL bindings, and IPC plumbing. Work on desktop and Android permission prompts ([bug 2010091](https://bugzilla.mozilla.org/show_bug.cgi?id=2010091), [bug 2010093](https://bugzilla.mozilla.org/show_bug.cgi?id=2010093)) is ongoing. Three Mozilla engineers — John Schanck, Martin Thomson, and Benjamin VanderSloot — are [active members](https://www.w3.org/groups/wg/fedid/participants/) of the W3C FedID Working Group, and Schanck has been providing substantive implementation-informed feedback on key spec PRs including the [credential presentation algorithm](https://github.com/w3c-fedid/digital-credentials/pull/419) and [request preparation algorithm](https://github.com/w3c-fedid/digital-credentials/pull/420). This is a significant development: while Mozilla maintains its concerns about the API's potential for misuse, it is evidently choosing to shape the API from within — through both spec work and implementation — rather than cede the design to other browser vendors. It signals that the Digital Credentials API is likely on a path toward three-browser support, albeit with Mozilla pushing for stronger privacy guardrails (including a proposed [transparency log](https://github.com/w3c-fedid/digital-credentials/issues/472) for credential requests). ### 6.4. Overview Table **Table 1: Browser Support for Digital Credentials API & Protocols (March 2026)** | Feature / Browser | Google Chrome (Android & Desktop) | Apple Safari (iOS & macOS) | Mozilla Firefox | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------- | | **Digital Credentials API (`navigator.credentials.get`)** | ✅ **Stable** (141) | ✅ **Stable** (26) | 🔧 **In Dev** ([Firefox 149](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), behind pref flag) | | **org.iso.mdoc via API** | ✅ **Yes** (via ISO 18013-7 Annex C under DC API) | ✅ **Yes** (**only**; `protocol: "org-iso-mdoc"`) | 🔧 TBD (macOS may use OS APIs; mdoc-only initially) | | **OpenID4VP via API** | ✅ **Yes** | ❌ **No** (Safari implementation is mdoc-only) | 🔧 TBD | | **Issuance via Web API (OpenID4VCI)** | 🔧 [Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) (Chrome 143) via `credentials.create()` | ❌ Browser API not for issuance (native app flows only) | ❌ N/A | | **Cross-device flow** | ✅ Desktop↔Mobile via CTAP/BLE QR handoff (opaque to browser) | ✅ Mac/iPad handoff to iPhone; non-Apple via QR + CTAP on iPhone | ❌ N/A | ## 7. Recommendations for Relying Parties For organizations (Relying Parties or RPs) that intend to request and verify digital credentials from users, the current landscape requires careful strategic planning. ### 7.1. Strategy: Prepare for a Dual-Protocol World Given that Safari (shipped Sept 15, 2025) exclusively supports direct `org-iso-mdoc` interactions (ISO 18013-7 Annex C) through the Digital Credentials API, and Chrome (shipped Sept 30, 2025) is **protocol-agnostic** supporting both **OpenID4VP** and **ISO 18013-7 Annex C** (mdoc), RPs aiming for the broadest possible reach should prepare to support interactions based on both approaches. This means architecting systems that can handle both protocol paths, as shown below. While this adds complexity, attempting to force all users down a single protocol path will likely exclude a substantial portion of the user base, either those on [iOS](https://www.corbado.com/blog/webauthn-errors) or those on Chrome/[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), depending on the chosen path. A pragmatic, albeit more development-intensive, approach is to build flexibility to handle both. ### 7.2. Understanding Information Disclosure Differences Relying Parties must be acutely aware that even when requesting the same logical piece of information (e.g., "is the user over 21?"), how this is defined in a request and how it is returned in a response can differ significantly between a direct mdoc query and an OpenID4VP query (which might use Presentation Exchange or DCQL). - **mdoc Selective Disclosure**: org.iso.mdoc has its own mechanisms for selective disclosure, typically involving the issuer creating salted hashes of individual data elements. The holder's wallet then reveals only the requested elements along with their salts, allowing the verifier to confirm them against the hashes without seeing other data. The request for specific elements is tied to predefined namespaces and data element identifiers within the mdoc standard. - **OpenID4VP Selective Disclosure**: OpenID4VP typically uses a query language like Presentation Exchange (DIF PE) or the newer Digital Credentials Query Language (DCQL) embedded within the presentation_definition of the request.. This allows RPs to specify the credential types and individual claims they need. The wallet then constructs a [Verifiable Presentation](https://www.corbado.com/glossary/verifiable-presentation) containing only the requested information, if supported by the credential format and wallet. RPs need to map their specific data requirements to these varying protocol structures. It is crucial to understand the nuances of how selective disclosure is implemented and requested in each protocol to ensure that only the minimum necessary data is requested and processed, thereby adhering to privacy best practices and data minimization principles. The format and structure of the disclosed data returned by the wallet may also differ, requiring distinct parsing and validation logic on the RP's backend. ## 8. Recommendations for Wallet Issuers For entities looking to issue digital credentials and provide wallet applications for holders, the operating system environment plays a crucial role. ### 8.1. Platform Considerations: iOS vs. Android Wallet [issuers](https://www.corbado.com/glossary/issuer) face distinctly different landscapes on [iOS](https://www.corbado.com/blog/webauthn-errors) and Android concerning wallet creation, system integration, and interaction with the Digital Credentials API. ![Android Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/android_digital_credential_cfe8d92b1e.png) - **Android**: Generally offers a more open ecosystem. The Android Credential Manager includes a Holder API that allows third-party native applications to register as credential holders. These registered holder apps can then participate in credential presentation flows mediated by the system, responding to requests from the Digital Credentials API (via Chrome) or [native app](https://www.corbado.com/blog/native-app-passkeys) verifiers. Android also explicitly supports OpenID4VCI for credential issuance, allowing users to choose a compatible third-party wallet to receive newly issued credentials. While native apps are the primary focus for full credential holder capabilities, the system is designed for broader participation. ![Apple Digital Credential](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/apple_digital_credential_f763cdaeb9.png) - **iOS**: Apple maintains tighter control over its ecosystem. While third-party wallet apps can exist on the App Store, their ability to deeply integrate as system-level credential holders for high-assurance credentials (like [mDLs](https://www.corbado.com/blog/mobile-drivers-license) intended for Apple Wallet) is often subject to Apple's specific processes and entitlements. Adding an ID to Apple Wallet, for instance, is a controlled flow involving state issuing authorities and Apple's [verification](https://support.apple.com/en-us/118260). For the Digital Credentials API in Safari, interactions will likely be closely managed, with a primary focus on org.iso.mdoc presented from authorized sources, namely Apple Wallet itself and registered third-party document provider apps. ### 8.2. Apple's Walled Garden for Wallet Creation Apple's "walled garden" approach is well-established, and their implementation of digital credentials is no exception. However, [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26) clarified the path for third-party participation. While Apple Wallet is the primary, built-in provider for credentials like state mDLs, Apple has introduced the **`IdentityDocumentServices` framework** for native [iOS](https://www.corbado.com/blog/webauthn-errors) apps. This allows third-party developers to build applications that can provision and present their own identity documents. To participate in the web flow, a [native app](https://www.corbado.com/blog/native-app-passkeys) must: 1. **Register Documents**: Use the `IdentityDocumentProviderRegistrationStore` to register the mdocs the app manages with the operating system. This registration includes the document type and the trusted certificate authorities for request signing. 2. **Implement an App Extension**: Add an "Identity Document Provider" UI App Extension to the project. This extension is responsible for displaying the authorization UI to the user when the app is selected during a web-based verification flow. This means that while creating a fully integrated wallet on iOS requires building a **native application** and using Apple's specific frameworks—not web technologies like PWAs—there is a clear, albeit tightly controlled, mechanism for third-party apps to act as document providers alongside Apple Wallet. This confirms that interaction with the Digital Credentials API in Safari is managed by the OS, which then dispatches requests to Apple Wallet or any other registered and authorized document provider app. ## 9. Conclusion: From Shipped to Governed The Digital Credentials API represents a significant advancement in the digital identity space, offering a more secure, user-centric, and privacy-preserving approach to identity verification and credential presentation. With **Chrome 141** (Sept 30, 2025) and **Safari 26** (Sept 15, 2025) shipping stable presentation support, and **Firefox 149** now carrying [baseline implementation code](https://bugzilla.mozilla.org/show_bug.cgi?id=2005077), the API is on a path toward three-browser coverage. We will keep this article up-to-date as the landscape changes. The period since October 2025 has been defined by the API's **maturation from experimental pipe to governed standard**. The [elimination of the open protocol registry](https://github.com/w3c-fedid/digital-credentials/issues/396) at TPAC (November 2025) is the clearest signal: the W3C FedID WG now explicitly names and governs the protocols the API supports. This enables comprehensive security and privacy review but also makes the Working Group a gatekeeper — a deliberate tradeoff that not all participants are comfortable with (notably, the [ISO paywall objection](https://github.com/w3c-fedid/digital-credentials/pull/401#discussion_r2721337228) from Ping Identity remains unresolved). Meanwhile, the API is **expanding from presentation to full lifecycle**: Chrome 143's [issuance Origin Trial](https://developer.chrome.com/blog/digital-credentials-api-143-issuance-ot) via `navigator.credentials.create()` allows websites to trigger wallet provisioning. But a [wallet selection binding vulnerability](https://github.com/w3c-fedid/digital-credentials/issues/382) — where malicious wallet apps can intercept issuance codes — is blocking government adoption of this feature. On the regulatory front, the EU's [ARF Topic F](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md) conditionally requires DC API support for all EUDI member state wallets, pending the spec reaching W3C Recommendation. Real-world adoption is accelerating: the [California DMV](https://github.com/stateofca/opencred/blob/main/CHANGELOG.md) has added DC API support, and conformance test suites are being developed by the [European Wallet Consortium](https://eudiwalletconsortium.org/). Challenges remain. The dual-protocol reality (Chrome's multi-protocol support versus Safari's mdoc-only focus) persists for relying parties. The question of [whether browsers must support all listed protocols or just one](https://github.com/w3c-fedid/digital-credentials/issues/439) is unresolved — directly tied to Apple's platform constraints. And privacy considerations remain the [single biggest gap](https://github.com/w3c-fedid/digital-credentials/issues/255) preventing progress toward Candidate Recommendation, with normative requirements for protocol inclusion criteria still unwritten. The spec is estimated to be 1–2 years from W3C Recommendation. ## Frequently Asked Questions ### How do I handle Safari and Chrome differences when implementing the Digital Credentials API? Safari 26 exclusively uses the `org-iso-mdoc` protocol string, while Chrome 141 supports both OpenID4VP and ISO 18013-7 Annex C. Relying parties must detect the browser and route to the appropriate protocol path. Selective disclosure also differs: mdoc uses salted hashes on predefined namespaces, while OpenID4VP uses query languages like Presentation Exchange or DCQL. ### Why is Mozilla implementing the Digital Credentials API if it has a negative standards position? Mozilla landed baseline DC API code in Firefox 149 (Q1 2026) while its formal negative standards position remains technically unchanged. Mozilla is choosing to shape the API from within rather than cede the design to other vendors. Three Mozilla engineers are active W3C FedID Working Group members providing implementation-informed feedback on key spec pull requests. ### What is blocking government issuers from adopting browser-mediated credential issuance via the Digital Credentials API? A wallet selection binding vulnerability allows malicious wallet apps to intercept issuance pre-authorization codes during flows triggered by `navigator.credentials.create()`. Government issuers have stated they will not adopt browser-mediated issuance until this is resolved. Chrome 143 launched an Origin Trial for issuance via OpenID4VCI, but the vulnerability remains open as of early 2026. ### What conditions must be met before EU member state wallets are required to support the Digital Credentials API? The EUDI ARF Topic F conditions include the DC API reaching W3C Recommendation status and meeting expectations around functionality, browser/OS neutrality, privacy and denial-of-service protection. The European Wallet Consortium has incorporated DC API test cases into its conformance testing program. The spec is currently estimated to be 1 to 2 years from W3C Recommendation. ### What specific protocols does the Digital Credentials API spec support after the November 2025 TPAC changes? The W3C FedID Working Group hardcoded five protocol identifiers: `openid4vp-v1-unsigned`, `openid4vp-v1-signed`, `openid4vp-v1-multisigned` and `org-iso-mdoc` for presentation, plus `openid4vci-v1` for issuance. User agents are expected to reject any protocol not on this list. Ping Identity raised a formal objection to the ISO 18013-7 inclusion, citing concerns about normatively referencing a paywalled specification.