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

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

• 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 the user or match via reference.

If personal data will be shared, 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.

Make clear:

• the supported routes to present the credential

• 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 to present options to user.

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.

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:

• 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

5. Present proof

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

Examples of presentation mechanisms:

• digital wallet presentation

• 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.

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

Use the outcome page.

---

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.

• 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.

• If presentation fof proof fails, do not leave users to a dead end instead enable retrying, alternative proof, or assisted support.