Verify Credentials with the DC API on Android (Chrome)

On Android, the W3C Digital Credentials API (DC API) is invoked by Chrome (or another current Chromium browser, such as Edge). When your page calls navigator.credentials.get(), Chrome passes the request to the Android Credential Manager, which presents the system wallet chooser and routes the request to the wallet the holder picks. Credential Manager is an open provider model: any installed app that registers as a digital credential provider can appear in that chooser, so the iGrant.io Data Wallet answers the request alongside whatever else the holder has installed.

This guide follows the same OpenID4VP send and verify flow as the Send and Verify Credential guide, but configures the request for the DC API on Android. Chrome on Android carries both DC API protocols, OpenID4VP over the DC API (responseMode: dc_api) and ISO/IEC 18013-7 Annex C (org-iso-mdoc), so Step 2 below lets you choose the protocol, credential format and response mode rather than fixing them for you. For the same flow on iPhone and iPad, where the choice is narrower, see DC API verification in Safari on iOS.

As a verifier on Android you will:

• Define the credentials or claims you require in a presentation definition, using a DC API response mode.
• Hand the request to Chrome, which invokes Credential Manager and the holder's chosen wallet.
• Receive the verifiable presentation returned by that wallet and validate its integrity and authenticity.

DC API prerequisite on Android:

1. Chrome 141 or later (or a current Chromium-based Edge), where the Digital Credentials API is on by default. Versions from Chrome 128 need the flag enabled at chrome://flags#web-identity-digital-credentials.
2. A wallet installed on the Android device that registers with Credential Manager as a digital credential provider.
3. Google Play services 24.0 or higher for the cross-device flow (a desktop QR code scanned with the phone), plus Bluetooth enabled on both devices for the proximity check.
4. A Legal Person ID (LPID) credential in your Data Wallet before trialling; see European Business Wallet Owner ID.

Step 1: Get the API Key

To obtain your API key, please contact [email protected]. Once you have received your API key, enter it in the field below and click the Set API Key button to save it for future use.

Step 2: Create Presentation Definition (Verifier Admin)

To create a presentation definition for requesting proof, you can run the code block below using the Run button. Alternatively, you can manually copy the code block and use it in the body of the API request provided here. Select the protocol and transport, DC API version, credential format and response mode in the Request panel below. The request body updates to match your selection. For the W3C Digital Credentials API, choose a DC API response mode (which sets responseMode to "dc_api" in the request body). When using a Signed DC API variant, expectedOrigins is required. It is prefilled with the origin this page is served from, so you can run the request straight away. In your own application, set it to your verifier origin so the wallet can detect replay from a malicious verifier.

Request

Protocol & Transport

OpenID4VP Version

Version: v1.0

ISO 18013-7

Annex C Request / Response

DC API Version

W3C Working Draft 26 June 2026

Credential Format

IETF SD-JWT

Response Mode

direct_post

Response

Tip: Once a presentation definition is created, the presentationDefinitionId can be reused to verify multiple credentials (Step 3).

Step 3: Create Verification Request (Verifier/Relying Party)

Now you can ask a wallet for the credential you defined in Step 2. When Step 2 succeeds it fills the presentationDefinitionId into the request below, and that id tells the wallet which credential to present, so check that it matches the one Step 2 returned before you click Run. Leave requestByReference set to true, which sends the wallet a link to the request instead of the whole request and keeps larger requests working smoothly. You can also copy the code block and use it in the body of the API request provided here.

Once the request succeeds, the Request Credential button becomes active. Clicking it hands the request to the browser, which invokes the wallet. Step 4 covers what happens next.

StatusClick Run to create the verification request.

Request

Response

The presentation definition provided adheres to the specifications outlined in the DIF Presentation Exchange standard, as detailed here.

Step 4: Send and Receive Verifiable Presentation (Android Device)

When you click Request Credential, Chrome takes over and hands the request to Credential Manager. What you see next depends on where the wallet is:

• Wallet on the same Android device: Credential Manager shows the system wallet chooser, listing every installed provider that can satisfy the request. Pick the Data Wallet, and it shows what is being requested and asks you to consent to share it. There is no QR code or camera step in this case.
• Wallet on another device: if you are browsing on a desktop, Chrome shows a QR code. Scan it with the Android phone (through Google Lens in the Google or Chrome app, or a camera app that supports the code) to pass the request to the wallet there, then consent to share. The two devices complete a Bluetooth proximity check, so keep them close together with Bluetooth on.

Either way, the wallet shows which claims are being requested before you agree to anything. Nothing is shared until you consent.

Once you consent, the credential is sent back to the page and a green Credential shared successfully message appears above the panels. The Request Credential button also changes to Credential Received, and the Response panel shows what was received.

Step 5: Send and Receive Verifiable Presentation (Verifier/Relying Party)

• The Verfier (Relying Party) receives the requested credentials and can verify it. They may read the received credential by executing the Read Verification History API.
• From the response received, the vpTokenResponse can be decoded using JWT Decoder.
• From decoded response, the verifiableCredential inside the 'vp' can be further decoded to view the received credentials.

Trust status of the verifier

The wallet checks whether the verifier can be matched against a recognised trust list. The verification response exposes this through the isVerifiedWithTrustList and trustServiceProvider fields. If the verifier cannot be matched, the Data Wallet shows a "Service provider not verified" warning. See The "Service provider not verified" notice and Trust in the Wallet Ecosystem.

Try it Yourself

Watch a short demo of verifying credentials with the Digital Credentials API in Chrome on Android:

Watch the Android DC API demo on YouTube

Where to go next

• Digital Credentials API overview, for what the API is, what iGrant.io has implemented, and the limitations to plan around.
• DC API verification in Safari on iOS, which uses ISO 18013-7 Annex C only and behaves differently enough to need its own request.
• OpenID4VP send and verify credentials, the redirect-based flow to keep as a fallback where the DC API is unavailable.