Skip to main content

DC API - Send and Verify Credentials (Android)

The W3C Digital Credentials API (DC API) lets a verifier (Relying Party) request verifiable credentials directly through the browser, which then invokes the wallet on the Android device. This guide follows the same OpenID4VP send and verify flow as the Send and Verify Credential guide, but configures the request for DC API and is tailored for Android devices.

The steps for verifiers are:

  • Define the specific credentials or claims they require through a presentation definition (using a DC API response mode).
  • Initiate a verification request to the Android device, invoked through the browser's Digital Credentials API.
  • Receive and validate the verifiable presentation returned by the wallet on the Android device, ensuring the data's integrity and authenticity.
DC API prerequisite: Requires a browser that supports the Digital Credentials API (Chrome 128+ or Edge) with the flag enabled at chrome://flags#web-identity-digital-credentials. For cross-device flows to Android, ensure Bluetooth is enabled on both devices.

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 credential format and response mode from the dropdowns. 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 and must contain your verifier origin URL (e.g. https://example.com) so the wallet can detect replay from a malicious verifier.

Request

Protocol & Transport
Version: v1.0
Annex C Request / Response
W3C Working Draft 26 June 2026
W3C VC (JWT)
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)​

To create the verification request, execute 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 available here.

After receiving the response, use the toggle to switch to DC API mode. The wallet on the Android device can then accept the credential request using the browser's W3C Digital Credentials API by clicking Request Credential.

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)​

The wallet on the Android device accepts (consents) to send the requested credentials.

When a QR code is shown for a cross-device flow, open Google Lens and point it at the QR code. Tap the link that appears to open the Data Wallet and continue the verification.

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 an "Untrusted Service Provider" notice. See The "Untrusted Service Provider" notice and Trust in the Wallet Ecosystem.