Digital Credentials API
Learn what the W3C Digital Credentials API (DC API) is, how it streamlines digital credential verification on the web, and how MATTR VII verifier capabilities support it alongside OpenID4VP and ISO/IEC 18013-7 to deliver smoother, more privacy-preserving online verification.
DC API support is currently offered as a tech preview. The Digital Credentials API specification itself is still under active development in the W3C Web Incubator CG, and platform implementations continue to evolve. As such, functionality may be limited, may not work in all scenarios, and could change or break without prior notice as browsers and operating systems update their implementations.
What is the Digital Credentials API?
The Digital Credentials API (DC API) is a web browser standard that lets websites request digital credentials, and digital wallets respond, directly through the browser.
Instead of redirecting a user from a website to a separate wallet app and back, the browser itself orchestrates the exchange. The user sees a single, consistent prompt and picks the credential that satisfies the request, regardless of which wallet on the device stores it.
The DC API is being incubated in the W3C Web Incubator Community Group and is incorporated into the ISO/IEC 18013-7:2025 technical specification for remote verification of mDocs.
This page is written from the verifier perspective. For the holder perspective, see the holder DC API overview.
Why the Digital Credentials API matters for verifiers
Until recently, online credential verification largely relied on redirect-based flows. A website would invoke a wallet via a custom URL scheme, hand off the user, and wait for the wallet to redirect back with a response. That model works, but it creates real friction:
- Users are presented with a long list of possible wallet apps and have to guess which one holds the right credential.
- Many users land in a dead-end, having picked a wallet that is not installed or does not hold the credential the verifier is asking for.
- Verifiers end up restricting the wallets they support to keep the experience manageable, which limits user choice and slows ecosystem growth.
The DC API addresses these issues at the browser and operating system level. Wallets register the credentials they hold with the operating system. When a website asks for a credential, the OS finds matching credentials across every registered wallet and shows the user a single, unified picker. The focus moves from choosing a wallet to choosing the right credential.
For verifiers, this translates into higher completion rates, fewer abandoned journeys, and broader reach. A single integration can serve users regardless of which wallet they happen to use, including wallets built into the operating system itself.
Where the DC API fits alongside OpenID4VP and ISO/IEC 18013-7
The DC API is a transport, not a replacement for the existing credential exchange protocols. It defines how a verification request and response move between a website and a wallet through the browser. The actual request-and-response messages still follow established standards.
| Standard / specification | What it defines | Relationship to the DC API |
|---|---|---|
| OpenID4VP | The request-and-response protocol used by a verifier to ask a wallet for a credential | OpenID4VP messages can be carried over redirects or over the DC API. ISO/IEC 18013-7 Annex D defines OpenID4VP over the DC API. |
| ISO/IEC 18013-5 | mDoc data model and in-person, proximity-based presentation | The DC API is not used for in-person flows. ISO/IEC 18013-5 underpins the credential format and signatures that 18013-7 then carries online. |
| ISO/IEC 18013-7 | Remote (online) verification of mDocs | Annex C defines mDoc device retrieval over the DC API. Annex D defines OpenID4VP over the DC API. |
In practice, this means a single DC API integration can serve both annexes of ISO/IEC 18013-7, and a verifier does not have to choose between OpenID4VP and the DC API. They work together.
MATTR's implementation supports both annexes via a single integration in the Verifier Web SDK, providing a consistent verification experience across platforms and browser types.
How verification works with the DC API
A DC API-based verification follows four broad steps. This view focuses on what the verifier does at each stage.
Issue a verification request
When a user interacts with a verifier web application that requires a credential, the verifier application initiates a DC API request through the user's browser. The browser invokes the DC API, which communicates with the mobile device and shares a request object.
The request object includes a presentation definition detailing the information the verifier requires, such as the type and format of credentials and any individual claims from those credentials.
The operating system gathers matching credentials
The mobile device queries all credentials that wallets have registered with the operating system as available for DC API requests. Matching credentials are presented to the user in a unified picker, regardless of which wallet application stores them.
From the verifier's point of view this stage is opaque. The verifier does not need to know which wallet ultimately serves the request, the integration is the same in either case.
The wallet returns a verifiable presentation
Once the user selects a credential and consents to share it, the wallet sends an encrypted verifiable presentation back through the DC API to the verifier application.
The browser ensures the response returns to the exact context where the request originated, maintaining session continuity and security.
The verifier validates the presentation
Once the verifier receives the verifiable presentation, the application decrypts it and applies verification checks to validate the credential's authenticity, the issuer's trust status, and the response's compliance with the original presentation request.
The DC API supports both same-device and cross-device flows. A single DC API integration handles both.
Same-device verification
Same-device flows involve a single mobile device running both the verifier web application and the wallets that store the user's credentials.
For example, consider a user applying for a loan through their bank's mobile website. When the site needs to verify the user's identity, it triggers a DC API request in the browser. The browser uses the DC API to query all credentials registered on the device and display the ones that can satisfy the request. The user authenticates, selects their driver's license, and approves sharing it. The wallet then creates and signs the presentation and returns it through the browser to the verifier application.
The DC API manages the entire flow within the browser context, eliminating the need for redirects or leaving the user's current experience. The user authenticates using platform-level biometrics, and the private key associated with the credential remains secure in the device's key store.
Cross-device verification
Cross-device flows involve two devices:
- One device (typically a desktop or laptop) runs the verifier application in a web browser and creates the presentation request.
- A second device (typically a mobile phone) houses wallets that store the required credentials and responds to the request.
The browser on the first device displays a QR code or other mechanism to initiate the cross-device flow. The user scans this with their mobile device, which invokes the DC API on the mobile platform. The mobile device queries registered credentials and presents them to the user.
For example, a user completing a tax return on their desktop computer is asked to verify their identity. The website displays a QR code, which the user scans with their phone. The mobile device then presents matching registered credentials, the user selects their national ID card, authenticates, and consents to sharing the information. The presentation is sent back to the desktop browser, where verification completes and the tax return process continues.
The DC API uses secure communication protocols with built-in proximity checks (such as CTAP 2.1 over Bluetooth Low Energy) to verify the devices are physically close together. This mitigates risks such as QR code replay attacks or session hijacking.
Security and privacy properties
The DC API provides several security and privacy advantages over redirect-based approaches that are particularly relevant for verifiers:
- Session continuity: Once the interaction completes or if the user cancels, the session continues in the original browser context without losing state or requiring navigation. The verifier does not have to design around redirect bounces.
- Proximity verification in cross-device flows: Cross-device flows use operating system-level proximity checks to ensure devices are physically near each other before proceeding, reducing risks from QR code screenshots or remote attacks.
- Reduced tracking surface: The DC API prevents unauthorized apps from silently tracking user interactions or accessing credential data without explicit user action, which lowers the verifier's exposure to abuse vectors that target redirect-based flows.
Platform support
The DC API is a web browser standard and is implemented differently across platforms:
- iOS: Supported on Safari version 26 and later, available on iPhone 11 and later running iOS 26.
- Android: Supported on Chrome and Chromium-based browsers version 138 and later.
The DC API is specifically designed for web applications running in browsers. Native mobile applications use platform-specific APIs to interact with digital credentials. For example, Android provides a platform-specific implementation called the DigitalCredential API, which is part of the Credential Manager framework.
How MATTR supports the DC API on the verifier side
The MATTR VII Verifier Web SDK embeds the DC API as a streamlined alternative to redirect-based OpenID4VP. The same SDK:
- Handles both same-device and cross-device flows with a single integration.
- Supports both Annex C (mDoc device retrieval over DC API) and Annex D (OpenID4VP over DC API) of ISO/IEC 18013-7.
- Accepts presentations from MATTR-built wallets, third-party wallets, and OEM wallets through one consistent integration.
This means a verifier integration built on MATTR VII does not need to be redesigned each time a new wallet category becomes important. The DC API surface stays the same.
Accepting credentials from OEM wallets
One of the most significant capabilities the DC API unlocks is the ability to accept credentials from OEM wallets. OEM wallets are credential wallets shipped natively on mobile devices by their manufacturers, such as those provided by Apple and Google. They are pre-installed, deeply integrated with the operating system, and increasingly used by governments and large issuers to distribute high-assurance identity credentials such as mobile driver's licenses and national identification cards.
Historically, integrating with an OEM wallet meant a separate, bespoke integration per wallet provider. The DC API changes this. Because OEM wallets register their credentials with the operating system just like any other DC API-compatible wallet, a verifier that implements the DC API can accept presentations from OEM wallets through the same integration it uses for any other wallet.
For organizations exploring this, the relevant questions are usually:
- Which OEM wallets are available in the jurisdictions and on the device platforms my users rely on?
- Which credential formats do those OEM wallets support, and how do those map to the credentials my verifier needs to accept?
- How do trust frameworks, issuer onboarding, and certification interact with OEM wallet acceptance?
MATTR works with relying parties, governments, and ecosystem partners on exactly these questions. If you are looking to accept credentials from OEM wallets, or to understand which OEM wallets your verifier should support, contact us so we can talk through the specifics of your deployment.
Frequently asked questions
What is the Digital Credentials API (DC API)?
The Digital Credentials API (DC API) is a web browser standard being incubated in the W3C Web Incubator Community Group. It defines how websites and browsers can request and present digital credentials directly through the browser, without redirecting the user to a separate wallet app. The DC API is also incorporated into ISO/IEC 18013-7 for remote verification of mDocs.
Why does the Digital Credentials API matter for web verification?
The DC API removes long-standing friction in online credential verification. Instead of asking users to pick between multiple wallet apps and bounce through redirects, the browser shows a single prompt with credentials that actually match the request. This improves completion rates, reduces dead-ends, and lets verifiers accept credentials from a wider set of wallets, including those built into mobile operating systems.
How does the DC API relate to OpenID4VP?
OpenID4VP is the request-and-response protocol that defines how a verifier asks for a credential and how a wallet replies. The DC API is the browser transport that carries those messages between the website and the wallet. OpenID4VP can be carried over redirects or over the DC API, and ISO/IEC 18013-7 Annex D describes how OpenID4VP runs over the DC API.
How does the DC API relate to ISO/IEC 18013-7?
ISO/IEC 18013-7 defines remote verification of mDocs. Annex C describes mDoc device retrieval over the DC API (currently supported on iOS and Safari), and Annex D describes OpenID4VP over the DC API (expected on Android and Chromium browsers). The DC API is the browser-level mechanism both annexes rely on.
Which browsers and platforms currently support the DC API?
The DC API is supported on iOS 26 and later with Safari 26 (on iPhone 11 and later), and on Chrome and Chromium-based browsers version 138 and later on Android. Implementations are evolving, so the exact behavior can change as browsers and operating systems update.
Can verifiers accept credentials from OEM wallets via the DC API?
Yes. One of the most important capabilities the DC API unlocks is accepting credentials from OEM wallets, which are wallets shipped natively by device manufacturers such as Apple and Google. Because the DC API lets the operating system aggregate credentials from any registered wallet, verifiers no longer need to integrate with each wallet individually. MATTR's verification capabilities are designed to accept presentations from OEM wallets via the DC API. To explore this for your deployment, contact us.
How does MATTR support the DC API on the verifier side?
The MATTR VII Verifier Web SDK integrates the DC API as a streamlined alternative to redirect-based OpenID4VP. A single integration handles both same-device and cross-device flows, supports both Annex C and Annex D of ISO/IEC 18013-7, and lets verifiers accept presentations from MATTR-built wallets, third-party wallets, and OEM wallets through one consistent integration.
How would you rate this page?
Last updated on