Digital Credentials API (2026): Chrome, Safari & Firefox

Last updated: March 26, 2026

A quick overview of Digital Credentials API support in major browsers:

The world of digital credentials is moving fast. Here's a snapshot of key developments and projections:

Want to experience digital credentials in action?

Try Digital Credentials

What Changed Since October 2025?

• Protocol governance shift: The W3C FedID WG eliminated the open protocol registry at TPAC (Nov 2025) and now hardcodes supported protocols directly in the spec: OpenID4VP, OpenID4VCI, and ISO 18013-7 Annex C. The API is no longer a "dumb pipe."
• Issuance arriving: Chrome 143 launched an Origin Trial for credential issuance via navigator.credentials.create(), expanding the API beyond presentation-only.
• Firefox implementing: Despite an unchanged negative standards position, Mozilla landed baseline DC API code in Firefox 149 with UX work ongoing.
• EU conditional mandate: The EUDI Architecture Reference Framework (Topic F) now conditionally requires DC API support for all member state wallets.
• Real-world adoption: California DMV added DC API support to its OpenCred platform (Feb 2026).

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 issuers navigating this fast-evolving landscape.

Proving identity reliably and securely has been a persistent challenge in the web's architecture for many years. 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 also stepped in, enforcing or providing national digital identity wallets and services. However, these solutions were often siloed, geographically limited, and not universally interoperable.

The fallback for identity verification 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. 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. 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. This escalating threat landscape underscores the urgent need for more secure, cryptographically verifiable online identity and verification mechanisms.

Want to experience digital credentials in action?

Try Digital Credentials

Understanding how digital credentials operate involves looking at the key players involved and the different technological layers that enable their functionality.

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, 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 and stores it in a digital wallet. The holder controls when and what information from the credential is shared.
3. Verifier (or 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.

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 digitally signs the credential, ensuring its authenticity and integrity. The holder, in turn, uses their private key, often secured within their digital wallet (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 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 Wallet for legally binding signatures), the focus here, particularly for the Digital Credentials API, is on identity assertion and attribute verification for online interactions, not primarily on these broader signing functionalities.

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.

Core Terminology:

• Digital credential: Any machine-readable credential (PDF with a barcode, ISO mDL, 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 → holder → verifier.
• Verifiable Credential API: A REST/HTTP service interface for issuing, storing, presenting and verifying VCs between back-end systems (issuers, wallets, verifiers).
• Digital Credentials API (DC API): 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, 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, 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 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 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.

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 information from users' digital wallets. 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/.

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 and 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 to eliminate the open protocol registry and instead hardcode a finite list of supported protocols 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).

The spec also now covers credential issuance via navigator.credentials.create(). Chrome 143 launched an Origin Trial for this, allowing websites to trigger wallet provisioning flows using OpenID4VCI. However, a wallet selection binding vulnerability — 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 through its Credential Manager system and also supports Cross-Device Digital Credentials API on desktop via CTAP/BLE-backed QR handoff.

The API extends the existing Credential Management API 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), 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:

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.

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. 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. 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 and the wallet/holder.

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 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 (derived from ISO 18013-5 and its extension ISO 18013-7 "Annex C") and the OpenID Foundation's OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) specifications.

• 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, which defines the mDL application, data structure, and protocols for in-person (proximity) presentation using technologies like NFC, Bluetooth, or QR codes. ISO/IEC 18013-7 extends this to enable online/remote presentation of mDLs. 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 have a strictly defined data structure based on 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-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 services, remote identity verification for bank account opening).

• Origin and Standardization: OpenID4VP (for presentation) and OpenID4VCI (for issuance) are specifications developed by the OpenID Foundation. They extend OAuth 2.0 to support the exchange of verifiable credentials. 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 is also maturing.
• Data Model: OpenID4VP/VCI are designed to be credential format-agnostic. They can carry W3C Verifiable Credentials (VCs) in JSON/JSON-LD or JWT formats, mdocs, 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, providing proof of qualifications (e.g., educational diplomas, professional certifications), membership attestations, and more. They are well-suited for online interactions where a relying party needs to verify claims from various issuers.

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.

The European Union Digital Identity (EUDI) Wallet is a major initiative aiming to provide all EU citizens and residents with a secure digital wallet for identity documents and attestations. The EUDI Wallet architecture and reference framework explicitly plan to support both mdoc (particularly for Mobile Driving Licenses) and W3C Verifiable Credentials, utilizing OpenID4VP and OpenID4VCI for presentation and issuance flows. The reference implementation includes support for OpenID4VP transferring mDocs and OpenID4VCI for issuing PIDs and mDLs in mDoc and SD-JWT-VC formats. This dual support by such a large-scale 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 now conditionally requires that EUDI Wallet Units and Relying Parties support the DC API for remote presentation and 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) has incorporated DC API test cases into its conformance testing program, and the NOBID consortium completed 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. Separately, the decision to hardcode the ISO 18013-7 reference in the spec has drawn an objection from Ping Identity, 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.

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.

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:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Android's Credential Manager natively supports OpenID4VP for presentation and OpenID4VCI for issuance, allowing Android apps to act as credential holders and verifiers using these standards. Google notes growing wallet support; Google Wallet is an early adopter, with Samsung Wallet and 1Password announced.

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:

As we correctly anticipated, WWDC25 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 session Verify identity documents on the web. 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 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:

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.

Mozilla originally expressed a negative standards position on the Digital Credentials API. Their concerns, documented in detail, are comprehensive and rooted in their mission to protect user privacy, 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 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, Mozilla has begun actively implementing the Digital Credentials API. In Q1 2026, baseline DC API support landed in Firefox 149 (behind a preference flag), tracked under meta bug 2004828. The source code is in mozilla-central, including DigitalCredential.cpp, WebIDL bindings, and IPC plumbing. Work on desktop and Android permission prompts (bug 2010091, bug 2010093) is ongoing.

Three Mozilla engineers — John Schanck, Martin Thomson, and Benjamin VanderSloot — are active members of the W3C FedID Working Group, and Schanck has been providing substantive implementation-informed feedback on key spec PRs including the credential presentation algorithm and request preparation algorithm.

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 for credential requests).

Table 1: Browser Support for Digital Credentials API & Protocols (March 2026)

For organizations (Relying Parties or RPs) that intend to request and verify digital credentials from users, the current landscape requires careful strategic planning.

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 or those on Chrome/Android, depending on the chosen path. A pragmatic, albeit more development-intensive, approach is to build flexibility to handle both.

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 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.

For entities looking to issue digital credentials and provide wallet applications for holders, the operating system environment plays a crucial role.

Wallet issuers face distinctly different landscapes on iOS and Android concerning wallet creation, system integration, and interaction with the Digital Credentials API.

• 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 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.

• 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 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. 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.

Apple's "walled garden" approach is well-established, and their implementation of digital credentials is no exception. However, WWDC25 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 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 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.

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, 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 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 from Ping Identity remains unresolved).

Meanwhile, the API is expanding from presentation to full lifecycle: Chrome 143's issuance Origin Trial via navigator.credentials.create() allows websites to trigger wallet provisioning. But a wallet selection binding vulnerability — 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 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 has added DC API support, and conformance test suites are being developed by the European Wallet Consortium.

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 is unresolved — directly tied to Apple's platform constraints. And privacy considerations remain the single biggest gap 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.

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.

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.

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.

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.

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.