---
id: openID4vc-dcapi-overview
title: Digital Credentials API (DC API) - Overview
hide_title: false
sidebar_label: Overview
slug: /openID4vc-dcapi-overview/
description: An introduction to the W3C Digital Credentials API (DC API), how it works in the browser, what iGrant.io has implemented for send and verify, and the practical findings and limitations to plan around.
keywords: [Digital Credentials API, DC API, W3C, OpenID4VP, ISO 18013-7, org-iso-mdoc, navigator.credentials, Data Wallet, EUDI Wallet, verifiable credentials, cross-device, Android, iOS]
---
> **Build this with an AI coding agent.** Install the iGrant.io Agent Skills, then ask your agent to build the integration:
>
> ```bash
> npx skills add L3-iGrant/skills
> ```
import Link from "@docusaurus/Link";
import NoteBox from "@site/src/components/NoteBox";
The W3C **Digital Credentials API (DC API)** lets a website request verifiable credentials directly from a wallet on the user's device, brokered by the browser and the operating system, without a redirect or a custom app link. This page introduces the API, explains how the iGrant.io Data Wallet uses it, and sets out the practical findings and limitations a new implementer should plan around.
If you want to try it, see the platform guides: DC API verification on Android with Chrome and DC API verification in Safari on iOS. The two flows differ enough that they are documented separately; see DC API on Android vs iOS below for the summary.
## What the DC API is
The Digital Credentials API is a browser API developed in the W3C Federated Identity Working Group. It exposes a single call that a relying party makes from a web page:
```js
const credential = await navigator.credentials.get({
digital: {
requests: [{ protocol, data }],
},
});
```
The browser and the operating system mediate the request: they present a wallet chooser, hand the request to the selected wallet, and return the wallet's response to the page. The request carries a `protocol` (for example, OpenID4VP or ISO 18013-7 Annex C) and a protocol-specific `data` object.
For example, a relying party asking for proof that the holder is over 18, as an OpenID4VP presentation over the DC API, builds the call like this:
```js
const credential = await navigator.credentials.get({
digital: {
requests: [
{
protocol: "openid4vp",
data: {
response_type: "vp_token",
response_mode: "dc_api",
nonce: "n-0S6_WzA2Mj",
dcql_query: {
credentials: [
{
id: "age_check",
format: "dc+sd-jwt",
meta: { vct_values: ["https://example.com/age-verification"] },
claims: [{ path: ["age_equal_or_over", "18"] }],
},
],
},
},
},
],
},
});
```
The wallet returns a `vp_token` in its response, which the relying party then verifies.
Two design properties matter for relying parties:
* **Browser and OS mediation.** The website never talks to the wallet directly and cannot enumerate installed wallets. The user chooses which wallet responds, and the browser binds the request to the page's origin, which makes the exchange phishing-resistant.
* **Same-device and cross-device.** On a phone, the wallet on the same device responds. On a desktop, the browser shows a QR code that the user scans with their phone; a secure, end-to-end encrypted channel with a Bluetooth (CTAP/BLE) proximity check is then established between the two devices.
## What iGrant.io has implemented
The Data Wallet supports the DC API for the **send and verify** (presentation) flow, where a verifier requests credentials and the wallet presents them through the browser. The implementation covers:
* **Protocols:** OpenID for Verifiable Presentations over the DC API (`responseMode: dc_api`) and ISO/IEC 18013-7 Annex C (protocol `org-iso-mdoc`).
* **Response modes:** DC API **Signed** and DC API **Unsigned**. Signed requests require `expectedOrigins` so the wallet can detect a replayed request from a malicious verifier.
* **Credential formats:** IETF SD-JWT and ISO/IEC 18013-5 mdoc/mDL. W3C VC (JWT) is not offered over the DC API.
* **Same-device and cross-device** presentation, with the cross-device flow driven by the browser's QR code.
* **Platform split:** the Android flow supports OpenID4VP and ISO 18013-7, while the iOS flow supports ISO 18013-7 Annex C only. This mirrors browser support (see the findings below), which is why the Android and iOS guides differ.
## DC API on Android vs iOS
A verifier cannot send one identical request to both platforms. The table below summarises what changes, and the two guides show the resulting requests in full.
| | Android | iOS |
| --- | --- | --- |
| **Invoking browser** | Chrome 141 or later, and current Chromium-based Edge | Safari 26 or later; every iOS browser is WebKit-based, so this applies to all of them |
| **Wallet invocation** | Chrome hands the request to the Android Credential Manager, which shows an open chooser of installed provider apps | iOS routes the request to the wallet layer and presents a system consent sheet; there is no open provider chooser exposed to the web |
| **Protocols and formats** | OpenID4VP over the DC API (`responseMode: dc_api`) and ISO 18013-7 Annex C (`org-iso-mdoc`); IETF SD-JWT and ISO/IEC 18013-5 mdoc/mDL | ISO 18013-7 Annex C only, signed requests, ISO/IEC 18013-5 mdoc only |
| **Requestable credentials** | Any credential an installed wallet can present, in SD-JWT or mdoc/mDL; the verifier is not limited to a fixed catalogue | Only the five fixed mobile document types Apple's Identity Document Services defines (EU age verification, EU PID, photo ID, Japan MyNumber, mDL), as ISO 18013-5 mdocs; arbitrary OpenID4VP or third-party wallet credentials cannot be requested (see [the supported document types](#3-ios-restricts-requests-to-a-fixed-apple-controlled-set-of-credentials)) |
| **Cross-device support** | Yes, from Chrome 136 on the desktop; needs Google Play services 24.0 or higher and a Bluetooth proximity check | Yes: a desktop browser shows a QR code that the iPhone scans, followed by a Bluetooth proximity check |
| **Native app without a browser** | Yes, through Credential Manager's `DigitalCredential` API | No; a web view is required, as Apple has no native app-to-app verification API |
Full walkthroughs: DC API verification on Android with Chrome and DC API verification in Safari on iOS.
## Findings and limitations
The DC API is promising but young. The points below are the main things to plan around, based on the current state of the specification and browser support.
### 1. The specification is still a draft
The DC API is a **W3C Working Draft** on the Recommendation track, having moved from the Web Incubator Community Group (WICG) to the W3C Federated Identity Working Group. It is stable enough to build against but is explicitly described as under active development, and breaking changes should be expected. The request shape has already changed once (from a `providers` array to the current `requests` array), and at the W3C TPAC meeting in November 2025 the open protocol registry was removed in favour of a fixed set of protocols named in the specification (OpenID4VP, OpenID4VCI, and ISO 18013-7 Annex C).
### 2. Android and iOS implementations differ
The two shipping implementations do not support the same protocols:
* **Chrome (Android and desktop)** supports both OpenID4VP and ISO 18013-7 Annex C (`org-iso-mdoc`), and uses the Android Credential Manager so any installed wallet can register as a provider.
* **Safari (iOS, iPadOS, and macOS)** supports the `org-iso-mdoc` protocol only, that is, ISO 18013-7 Annex C. On iOS the API is further restricted: Apple limits it to a small, Apple-controlled set of credential types, so the credentials that can be requested on iOS are narrower and gated by Apple, unlike Android's open provider model where any installed wallet can respond.
The practical consequence is that a relying party cannot send one identical request to every platform. The request has to be built per platform, which is why iGrant.io ships separate Android and iOS guides. The iOS restriction to a fixed set of Apple-approved credentials is covered in the next point.
The platforms also differ in whether a browser is required. The DC API is a web platform API, so on iOS it works only inside a browser or web view (Safari, and other iOS browsers, which are all WebKit-based). Apple has not shipped a native app-to-app verification API, so a native iOS app can act as a credential provider but cannot request credentials without a web view. On Android the same capability is also exposed natively through Credential Manager's `DigitalCredential` API, so a native Android app can request an OpenID4VP presentation directly, with no browser involved. A native verifier app can therefore use the DC API without a browser on Android, but not on iOS.
### 3. iOS restricts requests to a fixed, Apple-controlled set of credentials
On iOS the DC API can only request the mobile document types that Apple's Identity Document Services framework recognises, presented as ISO 18013-5 mdocs over ISO 18013-7 Annex C. There is no open provider model as there is on Android, so a relying party cannot request an arbitrary OpenID4VP credential or one held in a third-party wallet, only these document types.
Apple defines a fixed set of five mobile document type categories, enumerated as the possible values of the document-provider.mobile-document-types entitlement:
* **EU age verification** (`eu.europa.ec.av.1`)
* **EU personal ID (PID)** (`eu.europa.ec.eudi.pid.1`)
* **Photo ID** (`org.iso.23220.photoid.1`)
* **Japan MyNumber card** (`org.iso.23220.1.jp.mnc`)
* **Mobile driving licence, mDL** (`org.iso.18013.5.1.mDL`)
A document is only requestable if the holder has provisioned one of these types in a wallet on the device (for example a US state mDL under the mDL category, or the Japan MyNumber card). The set of categories is defined and gated by Apple, not open to arbitrary issuers. The two EU categories, age verification and PID, are the ones most relevant to European Digital Identity use cases.
Two further constraints apply. The verifier must obtain a signing certificate from Apple and use the Verify with Wallet mechanism, so the website is authenticated to the wallet through reader authentication (ISO 18013-5 and ISO 18013-7 Annex C) before any data is released. And because every requestable credential is an ISO 18013-5 mdoc, selective disclosure is supported, for example sharing only an "over 18" result, but the available set is fixed by Apple rather than open to any issuer.
### 4. Browser and OS support is recent and uneven
The API shipped in stable browsers only in late 2025: **Chrome 141** and **Safari 26** (September 2025). Same-device presentation on Android was available earlier, from Chrome 128, behind the flag at `chrome://flags#web-identity-digital-credentials`; cross-device presentation (a desktop QR scanned with an Android phone) arrived in Chrome 136. The DC API on Android also depends on Google Mobile Services: the cross-device flow requires Google Play services 24.0 or higher, and scanning its QR code was first available only on the Pixel camera, with other Android vendors now updating their camera apps to support it. Google Lens, reached through the Google or Chrome app, is one way to scan the code, but it is not itself the requirement. The dependency is Google Play services, not Google Lens, so devices without Google services are not supported for this flow. Firefox carries baseline code but Mozilla holds a negative standards position, so it should not be relied on. In short, coverage is improving quickly but is not yet universal, and older browser versions still need a flag.
### 5. The user experience has more friction than a redirect
Compared with a redirect-based OpenID4VP flow, the DC API adds steps and variability:
* The cross-device flow (verifier on one device, wallet on another) requires the user to scan a QR code shown by the verifier's browser, using the phone's camera or a supported QR scanner (Google Lens or a compatible camera app on Android, the Camera app on iOS), and then pass a Bluetooth proximity check between the two devices, so both must have Bluetooth on and be near each other. The camera or QR scan only appears in this cross-device case; it is the entry point for the hand-off, not a restriction on the API itself.
* The same-device flow, where the verifier and the wallet are on the same phone, shows an operating-system wallet chooser directly, with no QR code or camera step. Its appearance and behaviour still vary by platform and version.
* Until recently the API sat behind a browser flag, and the wallet invocation and consent screens are not identical across platforms.
For a first-time user this is less predictable than a single redirect, and it is worth testing the exact flow on each target platform rather than assuming a common experience.
### 6. Protocol and response-mode fragmentation
Even within the DC API there are several shapes to handle: OpenID4VP over the DC API, ISO 18013-7 Annex C (`org-iso-mdoc`), and encrypted response variants (`dc_api.jwt`). Signed and unsigned response modes behave differently, and signed requests require `expectedOrigins`. Getting a working end-to-end flow means matching the protocol, format, and response mode that the target platform and wallet actually support.
The DC API brings real benefits: in-browser, phishing-resistant presentation with no redirect, browser and OS mediation, and selective disclosure. Adoption is growing: the EUDI Wallet Architecture and Reference Framework conditionally requires DC API support (requirement OIA_08), and public issuers such as the California DMV have added it. Building on it now, while planning for change, is a reasonable bet.
## When to use the DC API
Use the DC API when you want an in-browser, phishing-resistant presentation without a redirect or app link, and your target users are on recent Chrome or Safari. Plan to build platform-specific requests (OpenID4VP plus ISO 18013-7 on Chrome; ISO 18013-7 Annex C on Safari), and keep a redirect-based OpenID4VP path as a fallback for browsers and platforms where the DC API is not available. Because the specification is still moving, isolate the DC API request construction so you can adapt to protocol and IDL changes without reworking the rest of your integration.
## Related pages and references
* Verify credentials with the DC API on Android (Chrome and Credential Manager)
* Verify credentials with the DC API in Safari on iOS (ISO 18013-7 Annex C)
* OpenID4VP - Send and Verify Credentials (redirect-based flow)
* OpenID4VCI credential issuance
* OpenID4VP credential verification
* [W3C Digital Credentials specification](https://www.w3.org/TR/digital-credentials/)
* [Digital Credentials API on Chrome for Developers](https://developer.chrome.com/blog/digital-credentials-api-shipped)
* [Cross-device Digital Credentials API in Chrome desktop](https://developer.chrome.com/blog/digital-credentials-cross-device-ot)
* [EUDI Wallet ARF, Digital Credentials API (Topic F, requirement OIA_08)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/f-digital-credential-api.md)