#Credential Presenting

The Wallet2 Service presents credentials to a verifier using OpenID4VP 1.0 with DCQL (Digital Credential Query Language) for credential matching. You hand the wallet a presentation request — typically an openid4vp:// URL from a verifier such as Verifier2 — and the wallet finds matching credentials, builds a presentation, and submits it.

All endpoints live under /v2/{target}/wallet-service-api/, where {target} is the wallet's resource path ({organization}.{tenant}.{wallet-id}).

#How It Works

Presenting a credential runs through four steps:

1. Resolve the request — parse the verifier's authorization request and read its DCQL query.
2. Match credentials — find stored credentials that satisfy the query.
3. Build the presentation — sign the selected credential(s) with the holder key.
4. Submit — send the presentation to the verifier's response endpoint.

For consent UIs, the Isolated Flow collapses resolve + match into a single preview call that also returns verifier display metadata and per-claim disclosure options, then you build-vp-token and send-response (or reject).

#Two Ways to Present

• Full flow — a single call (POST /v2/{target}/wallet-service-api/credentials/present) auto-matches credentials from the wallet's Credential Stores, signs, and submits. This is what the per-format guides below use.
• Isolated Flow — drive each step yourself.
  • Consent UI: preview → build-vp-token → send-response (or reject).
  • Advanced: resolve → match → build → send.
  • Also used to present credentials that aren't stored in the wallet.

#Transaction Data

When a Verifier2 authorization request includes OpenID4VP transaction_data, Wallet2 validates each type against the shared transaction-data-profiles configuration, then binds accepted items during presentation (KB-JWT hashes for SD-JWT VC; DeviceSigned namespaces for mDocs).

Discover the types this deployment accepts:

GET /v2/{target}/wallet-service-api/transaction-data-profiles

Requires ES_WALLET_PRESENT_CREDENTIALS_FULL or ES_WALLET_ISOLATED_PRESENT_CREDENTIALS. Keep Wallet2 types aligned with Verifier2 (and with Issuer2 authorizedTransactionDataTypes for mDoc holders).

#Selective Disclosure

For SD-JWT VC and mDL, the verifier asks for claims through the claims array of its DCQL query. In the full credentials/present call, the wallet discloses accordingly automatically.

In the Isolated Flow consent path, preview returns per-claim options (required / selectable). You can then pass selectedDisclosureOptions to build-vp-token so the holder can include or omit optional selectively disclosable claims (required claims remain disclosed).

• SD-JWT VC — the verifier's requested paths select which selectively-disclosable claims are revealed. Claims the issuer marked selectively-disclosable that the verifier does not request stay hidden; a claim that isn't selectively-disclosable is always present.
• mDL (mso_mdoc) — every data element is individually disclosable, so the wallet discloses exactly the elements the verifier lists in claims (by [namespace, element] path) and nothing else.

#Supported Formats

Choose the credential type that matches your use case — the flow is identical; the verifier's DCQL query determines what is matched and disclosed:

• SD-JWT VC (IETF) via OID4VP
• W3C VC via OID4VP
• mDL / mDoc (ISO 18013-5) via OID4VP

Need fine-grained control? See Isolated Flow.