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

Last checked: October 18, 2026

Presentation support is stable in Chrome, Safari and Edge; Chrome 155 also ships issuance. The W3C specification remains a Working Draft.

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

Try digital credentials in a live demo.

Try Digital Credentials

What Changed Since March 2026?

• Protocol migration: Chrome deprecates unspecified protocols from 151, with removal planned for 160.
• Safari 27: Virtual-wallet WebDriver tests and interoperability fixes improve integration testing.
• Conformance: OpenID4VP/VCI + HAIP self-certification opened in August, including a browser-API wallet profile.
• Still unfinished: The October 15 draft is not a Recommendation; Firefox remains in development and issuance wallet binding remains open.

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.

Try digital credentials in a live demo.

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.

Protocol governance: 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). Unrecognized or disallowed requests are filtered out; the call fails if none remain. 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 covers credential issuance via navigator.credentials.create(). Chrome announced its 143 Origin Trial on November 26, 2025. Chrome 155 shipped issuance support on October 6, 2026, for Android and desktop cross-device flows; the release source marks it stable. Wallet selection binding remains an open Candidate Recommendation blocker, with competing mitigations discussed on October 14; a selected wallet must not be able to redirect issuance to another wallet.

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:

// Prepare a complete OpenID4VP 1.0 request on the backend before the click.
// requestData includes a fresh nonce, dcql_query, response_mode and encryption metadata.
async function requestCredential(requestData) {
    const protocol = "openid4vp-v1-unsigned";
    if (
        typeof DigitalCredential === "undefined" ||
        !DigitalCredential.userAgentAllowsProtocol(protocol)
    ) {
        return; // Show an alternative verification flow.
    }
 
    try {
        // Invoke directly from a user gesture while transient activation is active.
        const credential = await navigator.credentials.get({
            digital: { requests: [{ protocol, data: requestData }] },
        });
        // Send credential.protocol and credential.data to the backend for verification.
    } catch (error) {
        console.error("Credential request failed:", error);
    }
}

This illustrates the OpenID4VP 1.0 browser API binding. Protocol permission does not guarantee a compatible wallet or credential is available.

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 — unrecognized or disallowed requests are filtered out. 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. For the Digital Credentials API, use the hyphenated protocol identifier org-iso-mdoc.

• 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. OpenID4VP 1.0 was approved as Final on July 10, 2025; OpenID4VCI 1.0 followed on September 16, 2025.
• 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). OpenID4VP 1.0 uses the Digital Credentials Query Language (DCQL); selective disclosure depends on the credential format.
• 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.

The EUDI ARF Topic F discussion paper sets out a conditional requirement for remote presentation: W3C Recommendation status, compliance with its functionality, neutrality, privacy and availability expectations, and broad browser/OS support. These conditions are not yet met; the October 15 specification is still a Working Draft. Do not equate the EUDI wallet rollout deadline with a current universal DC API mandate.

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.

October 2026 migration: Chrome's protocol-filtering plan deprecates unspecified protocols from 151 and schedules removal for 160. Use the standardized identifiers in §4 instead of legacy strings such as oid4vp.

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.

Safari 27 (September 2026): WebKit added WebDriver commands for simulated wallet responses, cancellation and waiting. It also fixed unknown-protocol filtering, Credential.type (now "digital") and stuck pickers after aborts.

Change underway: WebKit is implementing OpenID4VP behind a disabled-by-default flag. In the June 10, 2026 meeting, Apple's Marcos Caceres explicitly acknowledged regulatory pressure to support OpenID4VP. This signals a possible expansion beyond Safari's mdoc-only implementation, not confirmed released support.

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 confirmed released OpenID4VP support 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.

October 2026 status — 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. Released Firefox support remains unavailable.

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

Use DigitalCredential.userAgentAllowsProtocol() to select an allowed protocol. Support both paths when your wallet ecosystem needs them; a shared mdoc path can suffice when all target wallets support it.

Keep an alternative verification flow for unsupported browsers and users without a compatible wallet or credential.

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 1.0 query (which uses 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 1.0 uses a dcql_query to specify credential types and requested claims. DCQL is not nested inside presentation_definition; that parameter belongs to older Presentation Exchange flows. 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 is about proving a high-assurance claim on a one-off basis, showing a driver's license or an over-18 attribute from a wallet. Signing a user into their account is a separate problem, and it is solved today with passkeys. Corbado does not implement the Digital Credentials API. What Corbado ships is passkey authentication through Corbado Connect, built on the same platform authenticators and CTAP cross-device plumbing this article describes for credential presentation.

• Passkey-first login components: drop-in login and passkey-list UI, so your team ships the WebAuthn ceremony without wiring navigator.credentials.get() and error handling by hand.
• Opportunistic enrollment: the append flow prompts users to add a passkey after a traditional login, with graceful fallback if they decline.
• Relying-party config handled: Corbado manages related origins and the .well-known association files on the server side across every domain and app.
• Passkey management: users list, add and remove passkeys from a drop-in settings component.

The wallet and CTAP foundation is shared, so the teams tracking the Digital Credentials API for identity verification can ship passwordless account login on that same infrastructure now.

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 challenged the normative reference).

The practical next steps are narrower: migrate legacy protocol identifiers before Chrome's planned 160 removal, use OpenID conformance tests and Safari 27's virtual-wallet testing, and retain fallbacks for Firefox and unsupported wallets.

The October 15 Working Draft now requires all listed presentation protocols and recommends issuance support; that requirement does not establish what each browser ships. Issuance wallet binding remains open. EUDI's conditional requirements therefore should not be presented as an already-effective universal browser-API mandate, and there is no confirmed Recommendation date.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (more than 80% passkey activation rate). Talk to a Passkey Expert →

Safari's documented presentation path uses org-iso-mdoc; Chrome also supports OpenID4VP. Select a protocol with DigitalCredential.userAgentAllowsProtocol() and keep a fallback for unsupported wallets. OpenID4VP 1.0 uses dcql_query; mdoc uses namespaces and data elements. Selective disclosure depends on the credential format.

Mozilla landed baseline code in Firefox 149 behind a preference flag while retaining its negative standards position. Its engineers contribute to the W3C specification, but Firefox still has no released Digital Credentials API support as of October 18, 2026. Implementation work does not imply endorsement or a confirmed release date.

Wallet selection binding remains an open Candidate Recommendation blocker as of October 18, 2026. The concern is that a selected wallet can redirect issuance to a different wallet. Mitigations were still being debated on October 14. Chrome nevertheless shipped issuance support in Chrome 155 for Android and desktop cross-device flows.

EUDI ARF Topic F sets out conditional support for remote presentation: W3C Recommendation status, compliance with its technical and privacy expectations, and broad browser/OS support. The October 15, 2026 specification is still a Working Draft, so these conditions are not yet met. No confirmed W3C Recommendation date is available.

The listed identifiers are openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned and org-iso-mdoc for presentation, plus openid4vci-v1 for issuance. The October 2026 draft requires all listed presentation protocols and recommends issuance support. Unrecognized or disallowed requests are filtered out; the call fails if none remain.