Skip to content
bitcoinsv.design

Search the guide

Search the guide

Proving an age

How Example Tickets asks for proof that Anna is over 18 at checkout for an over-18 gig: one field from a Pass, the wallet's prompt, what happens when she has no Pass, and a refusal that is not an error.

The Corner Room is over 18 only, so Example Tickets has to know Anna is over 18 before it sells her a ticket. It does not need her name, her date of birth or a copy of anything. It asks her wallet for one field of a , "over 18", at the moment it needs it, and accepts "no" as an answer.

Identity explains what a Pass is and how a holder reveals one field. Asking for a Pass sets the rules for asking. This page applies them to one checkout.

Asking at checkout

a desktop checkout step for The Corner Room saying the venue is over 18 only, with one 'Prove you're over 18' button and a line listing what is and is not shared
a desktop checkout step for The Corner Room saying the venue is over 18 only, with one 'Prove you're over 18' button and a line listing what is and is not shared

Anna has picked one standing ticket and pressed Buy. Before the review screen, one step explains the condition: "The Corner Room is over 18 only. Prove it with a Pass from your wallet." The button reads Prove you're over 18. Under it are two short lines: "We'll see: over 18, yes or no." and "We won't see: your name, date of birth or address."

Signing in did not ask for this, and a gig with no age limit never shows this step. The question belongs to the gig, not to Anna's account.

Do

Show the age step only for gigs that have an age limit, and name the venue's rule as the reason: "The Corner Room is over 18 only", not "Verification required".

Do

List on the site, before the wallet prompt opens, the one thing the site will receive and the things it will not, in the same words the wallet is about to use.

Don't

Ask for a date of birth and work out the age on the site. The site then holds a fact it never needed, and the wallet's field-level choice is wasted.

The wallet's Pass prompt

Bitcoin SV Wallet's Pass prompt naming Example Tickets as the verifier, Example ID Service as the issuer, 'Over 18: yes' as shared, and name, date of birth and address as not shared
Bitcoin SV Wallet's Pass prompt naming Example Tickets as the verifier, Example ID Service as the issuer, 'Over 18: yes' as shared, and name, date of birth and address as not shared

Bitcoin SV Wallet shows the request as the pattern describes: who wants it, which Pass answers it, what is shared and what is not.

Example Tickets wants proof you're over 18.

Sent to:         Example Tickets (tickets.example.com)
From your Pass:  Example ID Service
Shared:          Over 18: yes
Not shared:      your name, date of birth or address

[Share]  [Not now]

The verifier line matters because a ticket site sells for many venues. Anna is sharing with Example Tickets, not with The Corner Room, and the prompt says so. A later request from the site for "over 18" and a name would be a new request, and the wallet would ask again (see Permissions and allowances).

Do

Request the field with Example Tickets named as the verifier, and if the venue itself will receive the answer, name the venue in the request too, so the wallet's "Sent to" line is true.

Do

Ask for the same single field, "over 18", at every age-restricted checkout, and never widen a later request because an earlier one was granted.

When Anna has no such Pass

a desktop checkout panel saying the wallet has no Pass that shows Anna is over 18, with 'Get a Pass' and 'Show ID at the door instead' as the two options and the basket still intact
a desktop checkout panel saying the wallet has no Pass that shows Anna is over 18, with 'Get a Pass' and 'Show ID at the door instead' as the two options and the basket still intact

Now suppose Anna's wallet holds no Pass that can answer "over 18". Her wallet tells her so in its own words, and the site receives no proof. The site does not say she failed anything. It says what is true and offers two ways on:

  • Get a Pass. "We accept over-18 Passes from Example ID Service and other issuers on this list." The list is a link, and it says who decided it. Getting a Pass happens on the issuer's site and may take longer than a checkout.
  • Show ID at the door instead. Where the venue and the law allow it, Anna can buy now and show photo ID on the night. Her ticket is marked for it, and the confirmation says so.

Her ticket choice stays in the either way.

Do

Name the issuers the site accepts, and who chose them, on the screen that tells somebody they have no suitable Pass.

Do

Offer a way to buy that does not depend on a Pass where the venue allows one, so missing a Pass costs Anna a step at the door rather than the ticket.

Don't

Send Anna to an issuer and empty her basket behind her. Keep the gig and the ticket she chose waiting for when she comes back.

When Anna says "Not now"

a calm grey panel on the checkout step saying Anna chose not to share proof of age, with 'Ask my wallet again' and 'Show ID at the door instead', in no error colour
a calm grey panel on the checkout step saying Anna chose not to share proof of age, with 'Ask my wallet again' and 'Show ID at the door instead', in no error colour

This time Anna has a Pass and chooses not to share it. The wallet returns a refusal, which is an answer, not a fault (see Failures that are not errors).

The site shows a plain grey panel, not a red one: "You chose not to share proof of age. We can't sell a ticket for this gig online without it." Under it, the same two ways on: Ask my wallet again and Show ID at the door instead. Nothing else on the page changes, and the site does not ask again on its own.

Do

Word a refusal as Anna's decision and its one consequence for this gig, and leave every other part of the site, including other gigs, working as before.

Don't

Reopen the wallet's Pass prompt automatically after a refusal, or on the next page load. The next request waits for Anna to press Ask my wallet again.

Open questions

  • Does "Show ID at the door instead" undercut the Pass, so that people skip it, or does it make the Pass feel optional in a good way?
  • Who should decide which issuers a ticket site accepts: the site, the venue, or a published list that many sites share?
  • If a Pass is revoked after Anna bought a ticket with it, should the ticket ? This design says no, because the check was true when it was made.
  • Should a second over-18 purchase ask the wallet again, or rely on the earlier check the site already stores?
  • Do people read "Sent to: Example Tickets" closely enough to notice when a different verifier is named?

Written from: /guide/patterns/signing-in/, /guide/patterns/permissions-and-allowances/, /guide/how-it-works/identity/, /guide/patterns/errors-and-failed-payments/, /guide/patterns/connecting-a-wallet/.

Checklist

The rules on this page, in a form you can work through.

10 rules