Digital Credentials API

What is the Digital Credentials API for holders?

The Digital Credentials API (DC API) is a web browser standard that lets credentials held in any compatible wallet respond to credential requests from websites, directly through the browser. For a holder, this means presenting a credential to a website without having to leave the browser, choose between several wallet apps, or guess which app holds the credential the website is asking for.

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 holder perspective, and is most relevant to teams building wallets and holder experiences. For the verifier perspective, see the verifier DC API overview.

What changes for holders

Before the DC API, online credential presentation typically meant a long redirect: the website triggered a wallet via a custom URL scheme, the holder was bounced into a wallet app, and the wallet redirected back to the website with a response. That model created familiar problems for holders:

• The "NASCAR" wallet picker: holders faced an overwhelming screen of wallet options, similar to the multitude of sponsor logos on NASCAR vehicles.
• Dead-ends: holders picked a wallet that turned out not to be installed, or that did not contain the credential the website was asking for.
• Lost context: redirects pulled the holder out of the website they were trying to complete a task on, sometimes losing in-progress state.

The DC API shifts the experience from choosing a wallet to choosing the right credential. The operating system queries every registered wallet on the device, aggregates matching credentials, and presents them to the holder in a single, unified picker. The holder picks the credential they want to share. The wallet that holds it serves the request behind the scenes.

For the holder, the practical consequences are:

• A single, OS-native picker, regardless of how many wallets are on the device.
• Only credentials that match the request appear, removing guesswork.
• No need to leave the browser, which keeps the holder's flow intact.
• A familiar authentication step (platform biometrics or device passcode) before sharing.

How wallets participate in the DC API

For a credential to appear in the operating system's picker, the wallet that holds it must register it with the OS as available for DC API requests. This registration happens when the wallet stores the credential, and is refreshed as credentials are added, updated, or removed.

At a high level, a DC API-capable wallet is responsible for:

• Registering credentials with the operating system so they can be discovered by DC API requests.
• Matching registered credentials against incoming DC API requests so the OS can surface only the relevant ones to the holder.
• Authenticating the holder at presentation time, typically using platform-level biometrics or a device passcode.
• Creating and signing the verifiable presentation using the cryptographic key bound to the credential, which remains secure in the device's key store.
• Returning the presentation through the DC API so the browser can deliver it back to the verifier's session.

From the holder's point of view none of this is visible. The wallet that actually serves the request is just the one that holds the credential the holder selected.

How a holder experiences a DC API request

A DC API-based verification flow looks roughly like this from the holder's perspective.

Same-device and cross-device flows for holders

The DC API supports two interaction patterns:

• Same-device flows: The holder is using the website on the same mobile device that holds their credentials. The DC API surfaces matching credentials directly, and the exchange happens entirely within the browser on that device.
• Cross-device flows: The holder is using the website on a different device, typically a desktop or laptop. The desktop browser displays a QR code (or similar mechanism). The holder scans it with their mobile device, which then invokes the DC API on the mobile platform. Matching credentials are presented on the mobile device. The holder authenticates and consents on the mobile device, and the presentation is delivered back to the desktop browser to continue the task.

Cross-device flows use operating-system-level proximity checks (such as CTAP 2.1 over Bluetooth Low Energy) to confirm the two devices are physically close together before the exchange proceeds. This protects against attacks where someone tries to use a screenshot of a QR code or hijack a session from afar.

Security and privacy properties for holders

The DC API is designed with several properties that directly benefit holders:

• No silent tracking: The DC API prevents unauthorized apps from silently tracking credential interactions. Sharing requires explicit holder action.
• Platform-level authentication: The holder authenticates using the same biometric or passcode mechanism they already use to unlock the device. The wallet does not need to re-implement authentication primitives, which reduces the chance of weaker custom implementations.
• Keys stay on the device: The private keys associated with credentials remain in the device's secure key store. Presentations are signed locally rather than by handing keys to a remote service.
• Selective disclosure: When the underlying credential format supports it (such as mDocs), the holder can share only the specific claims the website asks for, rather than the whole credential.
• Session continuity: If the holder cancels, the website returns to its original state. The holder is not left in an ambiguous redirect state.
• Proximity protection in cross-device flows: The browser and operating system enforce proximity checks for cross-device flows, which reduces the risk of remote QR-code based attacks.

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. For native holder apps, the platform-specific APIs are used instead, for example Android's DigitalCredential API, which is part of the Credential Manager framework. ISO/IEC 18013-7 defines two browser-level mechanisms that are relevant here:

• Annex C: mDoc device retrieval over the DC API, currently supported on iOS and Safari.
• Annex D (draft): OpenID4VP over the DC API, expected on Android and Chromium-based browsers.

A wallet that supports both annexes provides a consistent holder experience across platforms and browser types.

How MATTR supports the DC API on the holder side

MATTR provides two main paths for building holder experiences that work with the DC API:

• MATTR Pi Holder SDKs: Build your own wallet app, or add credential holding capabilities to an existing app. React Native, iOS, and Android SDKs are available, and integrate with the DC API where the platform supports it. The SDKs handle credential registration with the operating system, authentication, and presentation signing.
• MATTR GO Hold: A white-label wallet application that already includes DC API support. Apply your own branding without writing wallet code yourself.

In both cases, credentials stored in the wallet are registered with the operating system so they are discoverable through DC API requests, alongside other wallets on the device including OEM wallets. The holder sees a single picker and chooses the credential they want to share.

For platform-specific holder integration steps, see the iOS guide and Android guide.

How OEM wallets fit into the holder ecosystem

A growing share of high-assurance identity credentials, such as mobile driver's licenses and national identification cards, are issued into OEM wallets - the credential wallets shipped natively on iOS and Android by Apple and Google. From a holder's perspective, the DC API treats OEM wallets the same as any other compatible wallet on the device. They register their credentials with the operating system, and those credentials appear in the same unified picker.

The practical consequence for holders is that a credential issued into an OEM wallet can be presented to any website that supports the DC API, side by side with credentials held in third-party or MATTR-built wallets. Holders do not have to install additional apps to use OEM-held credentials, and do not have to remember which wallet a particular credential lives in.

For wallet builders and ecosystem partners thinking about how OEM wallets fit alongside their own holder experience, contact us to talk through the design.

Frequently asked questions

What is the Digital Credentials API (DC API) from a holder's perspective?

The Digital Credentials API (DC API) is a browser standard that lets credentials in any wallet on a device respond to requests from websites without redirecting the holder out of the browser. For holders, the practical effect is a single, operating-system-level prompt that shows credentials matching what the website is asking for, regardless of which wallet they live in.

How does a wallet participate in the DC API?

A wallet that supports the DC API registers the credentials it holds with the operating system. When a website triggers a DC API request, the operating system queries every registered wallet, aggregates the matching credentials, and presents them to the holder in a unified picker. When the holder selects a credential, the originating wallet creates and signs the presentation.

How is the DC API different from redirect-based wallet flows for holders?

In a redirect-based flow, the holder is bounced out of the website into a wallet app and then back, often after first having to pick a wallet from a long list. With the DC API, the holder stays in the browser. The operating system surfaces only the credentials that match the request, and the holder picks the credential, not the wallet. This tends to be faster, less confusing, and less prone to dead-ends.

Do MATTR-built wallets support the DC API?

Yes. MATTR-built wallets, including holder applications built with the MATTR Pi Holder SDKs and MATTR GO Hold, register the credentials they store with the operating system so they are discoverable through DC API requests. This lets MATTR-built wallets sit alongside other wallets, including OEM wallets, in the operating system's unified credential picker.

How do OEM wallets fit into the DC API ecosystem?

OEM wallets are credential wallets shipped natively by device manufacturers such as Apple and Google. Because OEM wallets register credentials with the operating system in the same way other DC API-compatible wallets do, holders can present credentials from OEM wallets and third-party wallets through the same browser experience. This expands the set of credentials a holder can use for online verification without having to install additional apps.

Which browsers and platforms currently support the DC API for holders?

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. Holders need a wallet that has registered credentials with the operating system, and a browser and OS version that support the DC API.