# Present a credential

Prove something to a service, organisation or authority by presenting an existing credential (or equivalent proof), with clear consent and a reliable outcome.

Use this pattern when a service:

* needs proof of identity, status, eligibility, or entitlement
* currently requests documents or certificates
* wants to reduce repeated document requests and revalidation

## Steps

{% @mermaid/diagram content="---
config:
theme: redux
layout: dagre
-------------

flowchart LR
A\["1. Service requests proof<br>"] --> B\["2. Choose how to proceed<br>"]
B --> C{"Which route?"}
C -- Use wallet --> W1\["3. Select credential<br>"]
W1 --> W2\["4. Give consent to share<br>"]
W2 --> W3\["5. Present proof<br>"]
W3 --> F\["6. See outcome and return to service<br>"]
C -- Paper / assisted --> P1\["3. Provide proof (paper/assisted)<br>"]
P1 --> F
C -- "Reference (on-site)" --> R1\["3. Enter reference<br>"]
R1 --> R2\["4. Match to record<br>"]
R2 --> R3\["5. Generate representation<br>"]
R3 --> R4\["6. Present proof<br>"]
R4 --> F

A@{ shape: rounded}
B@{ shape: rounded}
W1@{ shape: rounded}
W2@{ shape: rounded}
W3@{ shape: rounded}
F@{ shape: rounded}
P1@{ shape: rounded}
R1@{ shape: rounded}
R2@{ shape: rounded}
R3@{ shape: rounded}
R4@{ shape: rounded}" %}

<details>

<summary><strong>Example user flow</strong></summary>

<figure><img src="https://content.gitbook.com/content/u8moxPbFWK9pTxPYNIyh/blobs/KliTFnsCskz58eUxpSYx/Present%20a%20credential.png" alt=""><figcaption></figcaption></figure>

</details>

### 1. Understand the proof request

The service explains what needs to be proven and why, using plain language.

Make clear:

* what is being proven e.g. identity, age, residency, vaccination status&#x20;
* why it is needed at this point
* what will happen after proof is accepted or rejected

The service may allow users to generate or retrieve a usable proof on-site, for example by entering a reference number to print a QR code, where this is appropriate.

If the service needs to link the user to a credential first, [authenticate](https://specs.govstack.global/service-patterns/2.-functional-patterns/authenticate) the user or [match](https://specs.govstack.global/service-patterns/3.-step-patterns/matching) via reference.

If personal data will be shared, [ask for consent](https://specs.govstack.global/service-patterns/2.-functional-patterns/ask-for-consent) before the transfer.

### 2. Choose how to proceed

The user chooses a method to provide proof such as digital wallet, paper, card or QR code. &#x20;

Make clear:

* the supported routes to present the credential&#x20;
* the effort and time taken by each method
* what to do if they can’t use the preferred route for example, if no smartphone or low connectivity

Use [multiple choice question](https://specs.govstack.global/service-patterns/3.-step-patterns/ask-a-question#variants) to present options to user.&#x20;

Some services support on-site generation of proof (for example, entering a reference number at reception or kiosk to print a QR code). This can help users who do not have a smartphone, have low connectivity, or did not bring their credential.

This route typically involves:

* entering a reference number (or similar identifier)
* matching to an existing record
* generating a time-bound or context-specific representation (e.g. printed QR)

### 3. Select the credential (or source of proof)

If using a wallet, the user selects which credential to present, use a [multiple choice question](https://specs.govstack.global/service-patterns/3.-step-patterns/ask-a-question#variants).&#x20;

Make clear:

* which credential(s) are suitable for this request
* whether an existing credential can be reused
* how to switch route if none are suitable

Design guidance

* minimise decision fatigue
* do not expect users to understand issuer ecosystems

### 4. Give consent to share

The user reviews what information will be shared, who it will be shared with, and agrees to proceed.

Make it clear:&#x20;

* who is requesting the information (verifier)
* what will be shared
* purpose of sharing
* user’s ability to refuse and alternatives available

Use the [consent pattern](https://specs.govstack.global/service-patterns/2.-functional-patterns/ask-for-consent).

### 5. Present proof

Proof is presented to the relying party via the chosen route.

Examples of presentation mechanisms:

* digital wallet presentation&#x20;
* QR or code shown to staff or device
* reference number used for lookup
* paper certificate presented or submitted
* assisted verification where staff checks records

### 6. See the outcome and return to the service

The user sees whether proof was accepted, not accepted or if more information is needed.&#x20;

Tell the user what happens next, how to try again or choose another route if failed.&#x20;

Use the [outcome step](https://specs.govstack.global/service-patterns/3.-step-patterns/outcome).&#x20;

***

## Considerations

* User consent is essential. Presenting proof must feel like an informed choice, not a hidden data transfer.
* Offer paper or assisted routes where digital is not possible or appropriate. &#x20;
* Support offline presentation where feasible; avoid making connectivity a hard dependency.
* Consider scenarios where a user may be required to present proof on behalf of someone else and define acceptable routes. For example, a parent, carer, accountant.&#x20;
* If presentation fof proof fails, do not leave users to a dead end instead enable retrying, alternative proof, or assisted support.