Presenting SD-JWT VC Credentials via OID4VP 1.0

This guide shows how to present an IETF SD-JWT VC 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, selectively discloses, signs, and submits in a single call.

For SD-JWT VC, the wallet reveals only the claims the verifier requests in its DCQL claims array — 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, DID Store, and Credential Store — see Setup.
  • The wallet holds an SD-JWT VC — see Receiving SD-JWT VC Credentials.
  • A presentation request from a verifier (an openid4vp:// URL).

Present the Credential

This single call resolves the request, DCQL-matches credentials from the wallet's stores, selectively discloses the requested claims, 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=did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5In0&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).
  • 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 credential 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 SD-JWT VC to the verifier, disclosing only the requested claims.


Doing It Step by Step

The full-flow call above matches, selectively discloses, signs, and submits in one request. To preview which credentials and claims 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