01 · Holder device
The mobile credential stays under the holder’s control.
No personal fields are reproduced in this illustration.
How it works
One tap, one question, one answer.
This page follows a single verification from the moment a phone touches the verifier to the moment a counter moves — including everything that deliberately does not happen along the way.
Verification boundary
Static explanatory model · no credential or customer data
02 · Local request
age_over_21
intentToRetain=false
03 · Bounded result
One of three operator outcomes.
Only aggregate outcome counts continue to reporting.
Identity does not enter LaurelID and then get redacted; it is outside the requested data path.
01 · The sequence
Six moments, in order.
-
Staff open the verifier
The application is already activated and bound to this location. It shows a ready state — not a claim that a phone has been detected.
-
The patron taps
NFC engagement begins. The tap negotiates how the credential will be transferred; it does not carry the credential itself.
Why NFC first A tap is a deliberate physical act by the holder. It is the clearest possible consent signal at a busy checkpoint, and it removes the “which phone are we talking to?” ambiguity that pure radio discovery has.
-
The session moves to Bluetooth
The credential response travels over an encrypted BLE session bound to the engagement that just happened. The verifier reports “connecting” here, because that is what is true.
-
The verifier validates
Issuer signature, security object, element digests, device binding, and session integrity are all checked against authenticated trust material before any claim is read.
Fail-closed Anything short of a cryptographically valid proof is not a pass. A damaged, expired, unknown-issuer, or interrupted presentation produces
unable_to_verify, never an optimistic guess. -
Staff see one outcome
A single, unambiguous result with a single next action. The result clears itself so the next patron never sees the previous one.
-
A counter moves
The outcome is queued on the device and delivered to the platform, where it increments an aggregate counter for this location and day. If the network is down, this step simply happens later.
02 · The request
What the verifier asks for — all of it.
A mobile ID can prove “over 21” without revealing a birth date, because the credential carries signed age attestations as separate elements. LaurelID asks for exactly one.
The entire verification request Unchanged in every release
- document type
- org.iso.18013.5.1.mDL
- namespace
- org.iso.18013.5.1
- element
- age_over_21
- intentToRetain
- false
03 · The outcomes
Three answers, and no fourth.
The vocabulary is closed on purpose. A closed vocabulary is trainable in minutes and auditable in seconds.
verified outcome
Verified 21+
The mobile credential proves the guest is 21 or older.
Staff action: Proceed according to venue policy.
verified outcome
Under 21
The credential successfully proves the guest is not 21 or older.
Staff action: Refuse according to venue policy.
inconclusive outcome
Unable to verify
The verifier could not complete a trustworthy mobile-ID check.
Staff action: Use the approved manual procedure.
21+ Verified → proceed
The credential cryptographically proves the holder is 21 or older.
Under 21 → refuse per your policy
The credential answers that the holder is not 21 or older. What happens next is your policy, not ours.
Unable to verify → manual fallback
The check could not complete trustworthily. Staff fall back to your existing manual age check, exactly as they do today for a patron with no mobile ID.
04 · What does not happen
The steps a scanning product would take here.
No credential is read beyond the one element
There is no moment where the full document is decoded and then filtered. The request itself is narrow, so the wider data never enters the application’s memory.
No image is captured
No portrait, no document photo, no scan of a physical card. There is no camera step in this flow at all.
No patron record is created
Not on the device, not in transit, not in the database. There is no patron table for a record to go into.
No repeat-visitor identifier is derived
Nothing is hashed into a stable per-person value. “We only store a hash” is still an identity system; this is not one.
The enforced version of all of this is on the privacy architecture page.
Watch it happen at your own counter.
A thirty-day pilot at one location is the shortest honest way to answer whether this fits your floor.