Skip to main content

DC API - Send and Verify Credentials (iOS)

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 iOS 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 iOS 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 iOS device, invoked through the browser's Digital Credentials API.
  • Receive and validate the verifiable presentation returned by the wallet on the iOS 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 iOS, 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. On iOS, DC API runs over ISO 18013-7 Annex C only, so the Request panel below comes preconfigured: the credential format is ISO/IEC 18013-5 mdoc/mDL and the response mode is DC API, Signed. Because the request is signed, 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

ISO 18013-7 Annex C Request / Response
W3C Working Draft 26 June 2026
ISO/IEC 18013-5 mdoc/mDL
DC API, Signed

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.

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 (iOS Device)​

When you click Request Credential, the browser takes over and invokes the wallet. What you see next depends on where the wallet is:

  • Wallet on the same device: if you are browsing on the iPhone or iPad, the browser asks you to choose a wallet. The wallet then shows what is being requested and asks you to consent to share it.
  • Wallet on another device: if you are browsing on a desktop, the browser shows a QR code. Scan it with your iPhone or iPad to pass the request to the wallet there, then consent to share.

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