> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/standards/presentation/overview.md).

# Overview

How a Verifier asks a Holder to prove something.

Presentation is how a credential gets used. You ask a Holder to prove something - *are they over 18*, *are they a customer in good standing* - and their wallet answers with a **Verifiable Presentation (VP)**: a signed package carrying the credential, or with selective disclosure only the claims you asked for, plus proof that this wallet legitimately holds it.

Here you are the **Verifier**, and you don't have to be the Issuer. Issuance happens once; presentation happens every time the credential is used, often by parties the Issuer has never heard of. Verifying checks the Issuer's signature, the wallet's proof, and whether the credential has been [revoked](/standards/revocation/overview.md).

Presentation uses [OpenID for Verifiable Presentations (OID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html).

## The short version

You create a **presentation request** - a signed object saying what you're asking for. The Holder approves it in their wallet. A response arrives in your systems, encrypted for you. You have the platform verify it and hand you the claim values.

```mermaid
flowchart LR
    R["1. You request<br/>a presentation"] --> A["2. Holder approves<br/>in the wallet"]
    A --> V["3. Response reaches you,<br/>encrypted for your Tenant"]
    V --> C["4. Platform verifies it and<br/>returns the claim values"]
    style A fill:#e6f4ea,stroke:#34a853,color:#1a1a1a
    style V fill:#fce8e6,stroke:#ea4335,color:#1a1a1a
    style C fill:#e8f0fe,stroke:#4285f4,color:#1a1a1a
```

The request carries no personal data. The response - the `vp_token`, the VP as it travels - is the personal data, and the route it takes is what separates the three [presentation flows](/standards/presentation/choose-a-flow.md).

## Who does what

<table><thead><tr><th width="200">Party</th><th>Role</th></tr></thead><tbody><tr><td><strong>You</strong></td><td>Acting as Verifier: define what you accept, ask for proof, act on the result</td></tr><tr><td><strong>Platform</strong></td><td>Builds presentation requests, runs the OID4VP endpoints, verifies responses</td></tr><tr><td><strong>Wallet</strong></td><td>Holds the credential, shows the Holder what's being asked, produces the <code>vp_token</code></td></tr><tr><td><strong>Holder</strong></td><td>Your customer - decides whether to answer</td></tr></tbody></table>

## How presentation runs

Configure your Verifier and VP Schema once, then every presentation follows the same four steps:

{% stepper %}
{% step %}

#### Generate the presentation request

One call creates the request and the link or QR code the Holder responds to, and sets how the response comes back.
{% endstep %}

{% step %}

#### Receive the response

It arrives by the route you chose in step 1: straight into your page, fetched from the platform, or pushed to an endpoint you host.
{% endstep %}

{% step %}

#### Verify it

The platform validates the signatures and contents, and returns the claim values.
{% endstep %}

{% step %}

#### Track the result

Each presentation leaves a verification result record.
{% endstep %}
{% endstepper %}

```mermaid
sequenceDiagram
    actor U as Holder
    participant W as Wallet
    participant T as You
    participant D as Platform

    T->>D: 1 · Create the presentation request
    D-->>T: request link
    T-->>U: show the link or QR code
    U->>W: open it
    W->>D: fetch the request
    W-->>U: this is what's being asked
    U->>W: approve

    rect rgb(241, 243, 244)
        Note over U,D: 2 · The response travels back - by a route that differs per flow
    end

    T->>D: 3 · Verify the response
    D-->>T: result + claim values
    T->>D: 4 · Read the record
```

## What the platform stores

It depends on the route the response takes, and two of the three routes store nothing at all. Only Flow 2 writes the `vp_token`, and where it does pass through platform storage it is encrypted, scoped to your Tenant, and deleted once you verify it - or after 5 minutes if you never do. See [Personal Data and Encryption](/standards/security-and-privacy/personal-data-and-encryption.md).

## Where to go next

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3><i class="fa-route" style="color:$primary;">:route:</i></h3></td><td><strong>Choose a Flow</strong></td><td>Start here. Compare the three routes the response can take, and pick one.</td><td><a href="/standards/presentation/choose-a-flow.md">Choose a Flow</a></td></tr><tr><td><h3><i class="fa-display" style="color:$primary;">:display:</i></h3></td><td><strong>Flows 1 and 2 (through Frontend)</strong></td><td>Configuration, the two integration methods, and the verification result.</td><td><a href="/standards/presentation/flows-1-and-2.md">Flows 1 and 2 (through Frontend)</a></td></tr><tr><td><h3><i class="fa-server" style="color:$primary;">:server:</i></h3></td><td><strong>Flow 3 (direct to Backend)</strong></td><td>Work in progress. Configuration, the API, and the verification result for the push flow.</td><td><a href="/standards/presentation/flow-3.md">Flow 3 (direct to Backend)</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.toolkit.equs.ai/standards/presentation/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.