01 · Engage
NFC tap
The patron taps their phone to the verifier. The tap carries the device engagement, not the credential.
LaurelID Verifier
The check happens in your staff member’s hand.
An Android application that engages a mobile ID, validates it cryptographically against authenticated issuer trust material, and answers one question: is this person 21 or older?
01 · The exchange
Tap, then transfer, then decide.
Engagement begins with an NFC tap and completes over Bluetooth Low Energy — the pairing the ISO/IEC 18013-5 device-retrieval flow is built around. There is no QR handshake in the current release.
02 · Transfer
BLE session
The credential response travels over an encrypted BLE session bound to the engagement that just happened, so a response cannot be lifted and replayed into a different session.
03 · Validate
Cryptographic checks
Issuer signature, security object, element digests, device binding, and session integrity are all checked before any claim is read.
04 · Decide
One outcome
The age claim is read only from the verified document model. Anything short of a valid proof is not a pass.
02 · Minimal disclosure
One element. Retention declined.
A mobile ID can answer “is this person over 21?” without disclosing a birth date, because the credential carries pre-computed age attestations. The verifier asks for exactly one of them.
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
Why intentToRetain: false matters
It is a declaration to the wallet, carried inside the signed request, that the verifier will not store what it is shown. Wallets can surface that declaration to the holder. Setting it honestly is the difference between a privacy claim and a privacy property.
What this rules out
The verifier cannot answer a different age threshold, cannot produce a redacted ID image, and cannot be configured to collect a second element. If your workflow needs any of those, LaurelID is the wrong tool and we will tell you so during scoping.
03 · What staff see
Three screens, and no ambiguity between them.
The renders below are built from the product’s own outcome vocabulary and design tokens. They illustrate the decision states; they are not screenshots of a live shift.
21+ Verified
Proceed
pass
Under 21
Refuse per your policy
fail
Unable to verify
Use your manual fallback
unable_to_verify
04 · Operator experience
Built for a doorway, not a desk.
The verifier is designed around the constraints of a real checkpoint: low light, gloves, noise, a queue behind the person in front of you, and staff who were trained in five minutes.
Behavior Why
state is explicit Preparing, phone detected, connecting, receiving, verifying — never a claim the app cannot back
result auto-clears The outcome leaves the screen so the next patron never sees the previous one
fail-closed Anything short of a valid proof is not a pass
fallback preserved Your existing manual age check stays yours, untouched
stored result no local history screen · no patron log
05 · Trust material
Whose signature counts.
A verifier is only as good as the issuers it trusts. LaurelID accepts exact certificate bytes authenticated through the signed AAMVA Digital Trust Service VICAL or reviewed directly from an issuing authority's official endpoint. A wallet listing, URL, subject label, or credential-provided root is not a substitute.
Reviewed, not fetched blindly
Builds ship reviewed public trust files. VICAL refresh verifies the signed publication and provider chain; direct-source pins are admitted only after the official certificate bytes and jurisdiction binding are reviewed.
Rollback-protected
Activation is keyed to the authenticated publication date, so an older package cannot be replayed over a newer one. An invalid update leaves the last known-good copy in place.
Bounded offline life
A verification does not need a live network connection. Offline operation remains available only while both the device policy lease and the admitted signed trust publication are valid. Laurel begins refreshing trust before expiry and keeps a still-valid current bundle if a refresh fails. An invalid candidate never replaces it, and no grace period revives expired, revoked, rolled-back, or incorrectly signed trust material.
Not accepted as trust anchors
Android system or user CAs, roots supplied by the presented credential, imported roots, test IACAs, and indefinitely stale trust packages. Widening the trust set is the easiest way to make a verifier look more compatible and the fastest way to make it worthless.
Put a verifier at your own point of check.
A pilot puts real hardware in staff hands at one location for thirty days.