pass
The mobile credential proves the requested age threshold.
Verify age. Never collect identity.
A patron presents a mobile ID. Laurel Secure checks the age threshold on the reader. Your team gets only pass, fail, or unable to verify — never a name, birth date, photo, or ID number.
Decision made on-device Three closed outcomes Aggregate-only storage
Explanatory model · no live patron data
01 · The whole output
Three answers. No identity payload.
Staff need a trustworthy decision, not a copy of the credential. Laurel keeps the operational vocabulary deliberately closed and makes uncertainty explicit.
fail
The credential answers that the requested age threshold is not met.
unable_to_verify
The reader cannot complete a trustworthy check, so staff use the normal fallback.
02 · Why the boundary matters
Verification without an identity database.
The privacy advantage is structural: Laurel asks for the age threshold, receives the outcome, and has no patron entity or persistent patron profile behind it.
Identity-collection model
Reads identifying fields from the credential
Creates data linked to an individual check
Adds identity data to the breach surface
Result: proving age also means handling identity.
Laurel Secure
Requests only age_over_21
Returns one of three closed outcomes
Stores aggregate counters, not patron records
Result: the business gets an age decision without receiving identity.
03 · At the point of check
Understand the interaction in one glance.
A patron presents a mobile ID.
The credential stays on the patron’s device throughout the exchange.
The reader checks the age threshold locally.
Identity attributes are not sent to the Laurel platform for the decision.
Staff see one clear outcome.
Pass, fail, or unable to verify — with an ordinary fallback when needed.
04 · Where it fits
For teams that need an age decision at a real-world handoff.
The same narrow verification boundary can support different age-gated settings without turning those settings into collectors of patron identity.
Bars & nightclubs
A clear age outcome for staff at the door, without a persistent patron profile.
Ticketed venues
One verification model for age-gated entry points and their operating teams.
Age-gated sales
Local age checks for regulated counters, pickup points, and handoffs.
05 · What the platform keeps
Counts for operations. No patron record underneath.
Laurel stores aggregate outcomes. Day-level report buckets stay suppressed until they reach k=3, and the platform has no patron entity or persistent patron profile.
Storage boundary Enforced shape
outcomes aggregate counters
day reports hidden below k=3
patron entity none
identity profile not accepted · not stored
06 · Straight answers
The practical questions, without the pitch.
What if a patron does not have a supported mobile ID?
Staff use the business’s normal manual age-check procedure. Laurel is the mobile-ID path, not a claim that every patron carries one.
Does the platform receive a name or birth date?
No. Patron identity stays within the device-side exchange. The patron-derived value that crosses is the closed verification outcome.
Can a report reveal a single check?
Day-level buckets are suppressed before rendering until they reach the minimum group size of k=3.
See the boundary working at your own point of check.
Tell us where age gets checked and what your team needs to learn from a pilot.