> 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/issuance/overview.md).

# Overview

How you hand a credential to your user, from deciding who gets it to it landing safely in their wallet.

Issuance is how a credential comes into existence. You decide that a particular person is entitled to a particular statement about themselves - *this customer is in good standing*, *this person is over 18* - and the platform turns that statement into a **Verifiable Credential (VC)**: a small signed document that lives in the Holder's wallet and can be presented anywhere, without the verifier ever calling you.

Issuance uses [OpenID for Verifiable Credential Issuance (OID4VCI)](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html), the same protocol wallets use to collect credentials from any compliant issuer.

### The short version ⚡

You decide who should receive which credential. The Holder's wallet asks for it, proves the right person is collecting, and receives a freshly signed credential. The credential is written to the Holder's phone and nowhere else - the platform never keeps a copy of the issued VC.

### Who does what 👥

<table><thead><tr><th width="150">Party</th><th>Role</th></tr></thead><tbody><tr><td><strong>You</strong></td><td>Define the credential, decide who gets it, and supply the claim values</td></tr><tr><td><strong>Platform</strong></td><td>Creates Offers, runs the OID4VCI endpoints, signs the VC with your Issuer Key, maintains the Revocation Registry</td></tr><tr><td><strong>Wallet</strong></td><td>Collects the credential, proves the right person is collecting, and stores it under keys only the Holder controls</td></tr><tr><td><strong>Holder</strong></td><td>Your user - the person the credential is about</td></tr></tbody></table>

### What an Offer is 🎟️

An **Offer** is an invitation to collect one credential. The Holder receives it as an `openid-credential-offer://` link - shown as a QR code, sent as a deep link, or delivered straight into their wallet - and opening it starts the collection.

On the two pre-authorized flows, two codes travel with the Offer, doing different jobs:

| Element                 | What it proves                                                                                      | Lifetime                      |
| ----------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------- |
| **Pre-authorized code** | That *you* already authorized this issuance, so the Holder never logs in to your systems to collect | Carried in the Offer          |
| **`tx_code`**           | That the *right person* is collecting                                                               | 3 minutes, can be regenerated |

What changes between integrations is how the Holder receives the `tx_code` - the second decision on [Choose a Flow](/standards/issuance/choose-a-flow.md).

{% hint style="info" %}
On [Flow 2](/standards/issuance/flow-2.md) there is no pre-authorized code and no `tx_code` at all. The Holder signs in at your Authorization Server instead, which both authorizes the issuance and proves who is collecting.
{% endhint %}

An Offer that is never accepted stops working after 5 days. Until then, an EQUS Wallet keeps unaccepted Offers in **Pending Offers**, an inbox the Holder can come back to.

### How Issuance runs ⚙️

Whichever flow you use, every issuance follows the same outline:

```mermaid
flowchart LR
    A["Configure once<br/>Issuer and VC Schema"] --> B["The Holder's wallet<br/>asks for the credential"]
    B --> C["The wallet proves the<br/>right person is collecting"]
    C --> D["The platform signs it<br/>with your claim values"]
    D --> E["Stored on the<br/>Holder's phone"]
```

Each flow fills these steps in differently, and each flow page has its own detailed sequence.

### Two decisions, then a method 🔀

There are three issuance flows, and they differ in **how and when your claim values reach the platform**. Two of them then branch again, on **how the `tx_code` reaches the Holder**. Only once both are settled do you pick how to build it - direct API calls, a pre-built Embedded UI component, or the Operator Portal with nothing to build at all.

[Choose a Flow](/standards/issuance/choose-a-flow.md) walks through both decisions and points at the right pages.

<table data-card-size="large" 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-signs-post" style="color:$primary;">:signs-post:</i></h3></td><td><strong>Choose a Flow</strong></td><td>Compare the three flows, then decide how the code reaches the Holder.</td><td><a href="/standards/issuance/choose-a-flow.md">Choose a Flow</a></td></tr><tr><td><h3><i class="fa-key" style="color:$primary;">:key:</i></h3></td><td><strong>Issuer and VC Schema</strong></td><td>One-time setup, shared by every flow.</td><td><a href="/standards/issuance/configuration-issuer-and-vc-schema.md">Configuration: Issuer and VC Schema</a></td></tr></tbody></table>

### What the platform stores 🔒

Nothing personal survives issuance. On [Flow 1](/standards/issuance/flow-1.md) claim values are held encrypted for up to 5 days before collection; on the other two flows nothing personal is written at all. The issued VC itself is never stored. The full picture, including retention windows and encryption boundaries, is on [Personal Data and Encryption](/standards/security-and-privacy/personal-data-and-encryption.md).


---

# 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/issuance/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.