---
title: "Overview"
description: "Present verifiable credentials from an Enterprise wallet service via OID4VP 1.0 with DCQL (Wallet2 Service)."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/overview
generated: 2026-10-01
---
# Credential Presenting

The **Wallet2 Service** presents credentials to a verifier using [OpenID4VP 1.0](https://docs.walt.id/concepts/data-exchange-protocols.md) 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](https://docs.walt.id/enterprise-stack/services/verifier2-service/overview.md) — 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](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/isolated-flow.md) 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](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/isolated-flow.md)** — 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`](https://docs.walt.id/enterprise-stack/setup/configurations/config-files/transaction-data-profiles.md) 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](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/isolated-flow.md) 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](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/sd-jwt-vc.md)
- [W3C VC via OID4VP](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/w3c-vc.md)
- [mDL / mDoc (ISO 18013-5) via OID4VP](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/mdl.md)

Need fine-grained control? See [Isolated Flow](https://docs.walt.id/enterprise-stack/services/wallet2-service/credential-presenting/isolated-flow.md).

**Note:**

Using draft OpenID4VP (`type: wallet`, `/v1`)? See the [Wallet Service](https://docs.walt.id/enterprise-stack/services/wallet-service/overview.md) guides. That path requires `wallet-draft-routes`.