Digital Credentials API (2025): Chrome & Safari (WWDC25)

Last updated: July 15, 2025 (post-WWDC25)

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:

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 try digital credentials yourself in a 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):

1. Issue (VC API - issuer ↔ wallet): State DMV issues a Verifiable Credential that says "Holder is over 18".
2. Store (Wallet app - OS): Credential sits in the user's wallet with its crypto proof.
3. Request (navigator.credentials.get() via DC API - website → browser): Beer-shop website asks: "Show me proof the user is ≥18."
4. Present (DC API dispatches to wallet → OpenID4VP (protocol) → VC payload): Wallet shows a consent UI, user approves, wallet sends a verifiable presentation back.
5. Verify (VC API - beer shop back-end): Site's back-end verifies the signature and the issuer's DID/public key; grants access.

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 2025, the API is still described as undergoing significant changes. This highlights its active development phase. Despite this, its potential is significant. Chrome has been the first to ship something public, with its Origin Trial, allowing developers to experiment with its capabilities. Chrome also supports this natively on Android through its Credential Manager system and has recently also published support for Cross-Device Digital Credentials API usage on desktop.

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 is designed to be protocol-agnostic, meaning it can support various underlying protocols for credential exchange. However, two main families of protocols are central to current implementations and discussions: 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. 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.

The browser landscape for the Digital Credentials API is still taking shape, with notable differences in approach and support levels.

Google Chrome, particularly on Android, has been an early adopter and implementer of the Digital Credentials API. They have run Origin Trials and integrated it with Android's native Credential Manager. Chrome's implementation primarily leverages OpenID4VP as the protocol for requesting credentials via the navigator.credentials.get() API call. While OpenID4VP itself is format-agnostic and can carry org.iso.mdoc or W3C Verifiable Credentials as payloads, the practical emphasis from Google seems to be on the OpenID4VP flow as the transport mechanism. Android's Credential Manager also natively supports OpenID4VP for presentation and OpenID4VCI for issuance. This allows Android apps to act as credential holders and verifiers using these standards.

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. At the conference, Apple officially announced support for the API in Safari 26 (shipping with iOS 26 and other OS updates in Fall 2025), confirming that their implementation exclusively supports the org.iso.mdoc protocol 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.

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 has formally expressed a "negative" position on the Digital Credentials API proposal as it currently stands. Their concerns 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.

Mozilla acknowledges that such an API could offer utility over existing ad-hoc methods for credential presentation but emphasizes that new web platform features must demonstrably make the web better overall and prioritize users' interests. 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.

Table 1: Browser Support for Digital Credentials API & Protocols

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, with its significant market share, is likely to prioritize direct org.iso.mdoc interactions through the Digital Credentials API, and Chrome/Android are emphasizing OpenID4VP (which can carry mdocs or other Verifiable Credential formats), RPs aiming for the broadest possible reach should prepare to support interactions based on both approaches.

This means architecting systems that can:

1. Initiate credential requests via the navigator.credentials.get() API, potentially specifying different protocol parameters ("org.iso.mdoc" or "openid4vp") based on browser detection or user agent capabilities.
2. Process responses that may come directly in an mdoc format or as a vp_token via OpenID4VP, which then needs to be parsed to extract the underlying credential (which could itself be an mdoc or another VC format).

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 Android/Chrome, 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. As the ecosystem evolves, it is crucial for both relying parties and wallet issuers to adapt and embrace the potential of this new technology. We will keep this article up-to-date as the landscape changes.

However, challenges remain. Achieving true global interoperability between different credential formats, protocols, and wallet implementations is a significant undertaking. Addressing the valid concerns raised by organizations like Mozilla regarding privacy, exclusion, and user agency is paramount to ensuring these technologies serve humanity. The current fragmentation in browser support and protocol emphasis means that relying parties and wallet issuers must navigate a complex landscape for the time being.