Presenting mDL / mDoc Credentials via OID4VP 1.0

This guide shows how to present an ISO 18013-5 mDL / mDoc stored in an Enterprise wallet to a verifier using the Wallet2 Service. You hand the wallet a presentation request — for example one created with Verifier2 — and it matches, discloses the requested data elements, signs, and submits in a single call.

For mDL, the wallet discloses exactly the data elements the verifier requests in its DCQL claims array (by [namespace, element] path) — see Selective Disclosure. This page follows the single-call full flow; for previews and consent screens, see Isolated Flow.

Prerequisites

  • A wallet service with a linked KMS and Credential Store — see Setup.
  • The wallet holds an mDL / mDoc — see Receiving mDL / mDoc Credentials.
  • A presentation request from a verifier (an openid4vp:// URL).

Present the Credential

This single call resolves the request, DCQL-matches the mDoc from the wallet's stores, discloses the requested data elements, signs the presentation, and submits it to the verifier.

CURL

Endpoint: POST /v2/{target}/wallet-service-api/credentials/present

Example Request

curl -X POST \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v2/{org}.{tenant}.{wallet-id}/wallet-service-api/credentials/present' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{
  "requestUrl": "openid4vp://authorize?client_id=x509_san_dns%3Averifier.example.org&request_uri=https://verifier.example.org/request/abc123"
}'

Path Parameters

  • orgID String — Organization host alias.
  • target resourceIdentifier — The wallet's resource path, e.g. waltid.tenant1.wallet.

Body Parameters — Wallet2PresentCredentialRequest

  • requestUrl String — The OID4VP authorization request URL from the verifier.
  • keyReference (optional) String — Full resource path of the key to sign the presentation with. Defaults to the first key in the wallet's linked KMS (or the service's configured static key if the KMS has none).
  • key (optional) Object — Inline serialized key ({ "type": "jwk", "jwk": { … } }). Takes precedence over keyReference.
  • did (optional) String — DID to present as. Defaults to the first DID in the wallet's linked DID Store (or the configured static DID). mDocs typically bind to the raw key rather than a DID.
  • runPolicies (optional) Boolean — When true, applies configured holder policies before presenting and blocks if a policy denies it. Omitted or false skips policy enforcement.

Example Response — WalletPresentResult

{
  "transmission_success": true,
  "verifier_response": {
    "status": "received",
    "message": "Presentation received and is being processed."
  }
}
  • transmission_success Boolean — Whether the wallet successfully transmitted the presentation to the verifier's response endpoint.
  • verifier_response Object — The raw response returned by the verifier. For a direct_post verifier (e.g. Verifier2) this is { "status": "received", "message": "…" }; some verifiers instead return a redirect_uri.
  • redirect_to String (optional) — Present only when the verifier returns a redirect URL to send the user to; absent for direct_post.
  • get_url / form_post_html String (optional) — Populated instead of redirect_to for the redirect (get_url) or form_post (form_post_html) response modes.

Response Codes

  • 200 — Presentation built and submitted.
  • 400 — The presentation request could not be resolved (e.g. an unfetchable request_uri).

    When the request resolves but no stored mDoc satisfies the DCQL query, the call still returns 200 with "transmission_success": false and the verifier's DCQL-fulfillment error inside verifier_response — it does not return 400.

  • 401 — Invalid authentication.

🎉 You've presented an mDL / mDoc to the verifier, disclosing only the requested data elements.


Doing It Step by Step

The full-flow call above matches, discloses, signs, and submits in one request. To preview which data elements will be shared before presenting, drive the isolated endpoints yourself:

previewbuild-vp-tokensend-response (or reject)

Advanced resolve/match steps remain available for custom matching. Each step and the isolated inline variants are documented in Isolated Flow. You can also use the full-flow credentials/present endpoint when you do not need to inspect or approve intermediate results.


Next Steps

Last updated on August 18, 2026