#Credential Presenting

The Wallet API v2 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.

#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 /wallet/{walletId}/credentials/present) auto-matches credentials from the wallet's credential stores, signs, and submits. This is what the credential 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 (managed externally).

#Selective Disclosure

For SD-JWT VC and mDL, the verifier asks for claims through the claims array of its DCQL query. In the full POST /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).

What "only what's asked" means differs by format:

• SD-JWT VC — the verifier's requested paths select which selectively-disclosable claims are revealed. Claims marked selectively-disclosable by the issuer that the verifier does not request stay hidden; a claim that isn't selectively-disclosable is always present and can't be withheld. If the verifier sends no claims at all, only the always-present (non-SD) claims are shared.
• 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.

// A verifier asking (via DCQL) for just two claims of an SD-JWT VC
"claims": [
  { "path": ["given_name"] },
  { "path": ["birthdate"] }
]

#Supported Formats

• SD-JWT VC (IETF)
• W3C VC (JWT-signed)
• ISO 18013-5 mDL

#Start Presenting

Choose the credential type that matches your use case:

• SD-JWT VC via OID4VP
• W3C VC via OID4VP
• mDL via OID4VP

Need fine-grained control? See Isolated Flow.