Skip to main content

Digital Credentials API (DC API) - Overview

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: Send and Verify Credential (Android) and Send and Verify Credential (iOS).

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:

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:

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.

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 government-issued IDs that Apple has enabled in Apple Wallet, 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 the document types Apple currently supports.

As of mid-2026 those are:

  • US mobile driving licences and state IDs (mDL), available in a growing set of US states and territories (14 as of mid-2026): Arizona, California, Colorado, Georgia, Hawaii, Illinois, Iowa, Maryland, Montana, New Mexico, North Dakota, Ohio, West Virginia and Puerto Rico.
  • US passport Digital ID, from iOS 26.1 on iPhone 11 or later, where the user creates a Digital ID from a valid US passport. It is accepted for identity and age checks and for domestic (TSA) travel, and is not a replacement for a physical passport.
  • Japan My Number Card, from iOS 18.5, added through the Mynaportal app, carrying both the mobile document and Japan Public Key Infrastructure (JPKI) functionality.

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 a government ID in mdoc format, selective disclosure is supported, for example sharing only an "over 21" 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.

Why adopt it despite the rough edges: 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.