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.
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
orgIDString — Organization host alias.targetresourceIdentifier — The wallet's resource path, e.g.waltid.tenant1.wallet.
Body Parameters — Wallet2PresentCredentialRequest
requestUrlString — 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 overkeyReference.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 — Whentrue, applies configured holder policies before presenting and blocks if a policy denies it. Omitted orfalseskips policy enforcement.
Example Response — WalletPresentResult
{
"transmission_success": true,
"verifier_response": {
"status": "received",
"message": "Presentation received and is being processed."
}
}
transmission_successBoolean — Whether the wallet successfully transmitted the presentation to the verifier's response endpoint.verifier_responseObject — The raw response returned by the verifier. For adirect_postverifier (e.g. Verifier2) this is{ "status": "received", "message": "…" }; some verifiers instead return aredirect_uri.redirect_toString (optional) — Present only when the verifier returns a redirect URL to send the user to; absent fordirect_post.get_url/form_post_htmlString (optional) — Populated instead ofredirect_tofor the redirect (get_url) orform_post(form_post_html) response modes.
Response Codes
200— Presentation built and submitted.400— The presentation request could not be resolved (e.g. an unfetchablerequest_uri).When the request resolves but no stored mDoc satisfies the DCQL query, the call still returns
200with"transmission_success": falseand the verifier's DCQL-fulfillment error insideverifier_response— it does not return400.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:
preview → build-vp-token → send-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
- Present other credential types — SD-JWT VC or W3C VC.
- Receive more credentials — Credential Receiving.
- Manage stored credentials — list and retrieve credentials in the wallet.
