---
id: openID4vc-send-verify-credentials-dcapi-android
title: Verify Credentials with the DC API on Android (Chrome)
hide_title: false
sidebar_label: Send and Verify on Android (Chrome)
slug: /openID4vc-send-verify-credentials-dcapi-android/
description: Verify credentials in Chrome on Android using the Digital Credentials API, with Credential Manager picking the wallet over OpenID4VP or ISO 18013-7.
keywords: [DC API on Android, Chrome Digital Credentials API, Android Credential Manager, OpenID4VP dc_api, ISO 18013-7 Annex C, credential verification, verifiable credentials, Organisation Wallet, European Business Wallet, EUDI Wallet, Android]
---

> **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
> ```
>
> This page maps to the `igrantio-dcapi-android` skill. Install just that one with:
>
> ```bash
> npx skills add L3-iGrant/skills -s igrantio-dcapi-android
> ```


import Link from "@docusaurus/Link";
import NoteBox from "@site/src/components/NoteBox";
import YouTubeEmbed from "@site/src/components/YouTubeEmbed";

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 <Link to="/docs/openID4vc-send-verify-credentials/">Send and Verify Credential</Link> 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 <Link to="/docs/openID4vc-send-verify-credentials-dcapi-ios/">DC API verification in Safari on iOS</Link>.

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.

<NoteBox title="DC API prerequisite on Android:" variant="tip">
<ol>
<li>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 <code>chrome://flags#web-identity-digital-credentials</code>.</li>
<li>A wallet installed on the Android device that registers with Credential Manager as a digital credential provider.</li>
<li>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.</li>
<li>A Legal Person ID (LPID) credential in your Data Wallet before trialling; see <Link to="/docs/european-business-wallet-owner-id/">European Business Wallet Owner ID</Link>.</li>
</ol>
</NoteBox>

### Step 1: Get the API Key

To obtain your API key, please contact [support@igrant.io](mailto:support@igrant.io?subject=Request%20API%20Key). 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.

import { ApiKeyManager } from "@site/src/components/ApiKeyManager";

<ApiKeyManager />

### 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](/docs/openid4vc-api/config-digital-wallet-open-id-presentation-definition). 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.

import Step2 from "@site/src/components/VerificationDcApi/Step2";

<Step2 />

<NoteBox title="Tip:" variant="tip">
Once a presentation definition is created, the <code>presentationDefinitionId</code> can be reused to verify multiple credentials (Step 3).
</NoteBox>

### 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](/docs/openid4vc-api/config-create-digital-wallet-open-id-verification-request-v-3).

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.

import Step3 from "@site/src/components/VerificationDcApi/Step3";

<Step3
  initialJsonData={{
    presentationDefinitionId: "<presentationDefinitionId>",
    requestByReference: true,
  }}
/>

The presentation definition provided adheres to the specifications outlined in the DIF Presentation Exchange standard, as detailed [here](https://identity.foundation/presentation-exchange/).

### 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](/docs/openid4vc-api/config-read-digital-wallet-open-id-verification-history-v-3).
* From the response received, the `vpTokenResponse` can be decoded using [JWT Decoder](/docs/devtools-jwt-decoder/).
* From decoded response, the `verifiableCredential` inside the 'vp' can be further decoded to view the received credentials.

:::info 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](/docs/trust-untrusted-service-provider/) and [Trust in the Wallet Ecosystem](/docs/trust-overview/).
:::

### Try it Yourself

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

<YouTubeEmbed
  videoId="5kh5R4RsyPE"
  title="Verify Credentials with the DC API on Android using Chrome and Credential Manager"
  description="An Android walkthrough: a verifier (relying party) requests verifiable credentials from an EUDI Wallet in Chrome on Android over the W3C Digital Credentials API, using OpenID4VP with responseMode dc_api and ISO 18013-7 Annex C. The demo shows Chrome handing the request to the Android Credential Manager, the system wallet chooser listing installed providers, the holder consenting to share, and the verifier receiving and verifying the presented credential."
  thumbnailUrl="https://i.ytimg.com/vi/5kh5R4RsyPE/maxresdefault.jpg"
  uploadDate="2026-07-18"
  duration="PT1M38S"
  watchLinkText="Watch the Android DC API demo on YouTube"
/>

### Where to go next

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