Frequently asked questions
The questions every evaluation asks.
Grouped by who usually asks them. Where the honest answer is no, it says no.
01
The product
What does LaurelID actually do?
It verifies that a patron presenting an ISO/IEC 18013-5 mobile ID is 21 or older. The check runs on an enterprise Android verifier in a staff member's hand, and produces one of three outcomes: pass, fail, or unable_to_verify.
What does the platform receive from a check?
One of the three outcomes, plus operational envelope fields: a random event ID used only for retry de-duplication, the device and location identifiers, the occurrence time, the application version, an optional configuration version, and a closed failure category used only when the outcome is unable_to_verify. There is no other legal field in the contract.
Can it check an age other than 21?
Not in the current release. The verifier requests the age_over_21 element only, so it cannot answer a different threshold. A different threshold would be a different request and would require its own validation.
Does it read physical ID cards?
No. LaurelID is the mobile-ID path. There is no barcode scanner and no camera step. Patrons without a mobile ID go through your existing manual procedure, unchanged.
Is this an online or remote age check?
No. It is an in-person, proximity-based verification over NFC and BLE. It does not verify age for an online order at the point of purchase.
02
Privacy
Do you receive a name, birth date, or photo?
No. None of those are requested, so none are received. There is no column, blob path, or contract field for any of them, and the device-to-platform schema rejects unrecognized fields rather than stripping them.
Do you create a repeat-visitor identifier?
No. No stable per-person value is derived anywhere, on the device or on the platform. Hashing a document number would produce exactly such a value, so we do not do it.
Can a report identify one person?
No. Report rows below a minimum group size of three are withheld in the database query and re-checked in API responses, exports, and contracts, for every role including the highest.
What happens to patron data in a breach?
There is none to expose. That is the core claim, and it is a property of the schema rather than of a policy — which is why we would rather your reviewer read the privacy architecture than a compliance statement.
03
Compatibility
Which mobile IDs work today?
The checked-in evidence records physical passes for 15 jurisdictions in both Apple Wallet and Google Wallet on Elo M51, and 14 have also passed the canonical production gates. Arkansas is physically qualified in Apple Wallet and Google Wallet, but official issuing-authority certificate binding remains pending; it is not production enabled. Current production support appears only after the compatibility page validates matching live operational status; otherwise no pair is presented as Supported.
Does Google Wallet work?
Yes, on the same terms as Apple Wallet. Google Wallet carries state-issued IDs built on the same standard, and the checked-in evidence records physical Google Wallet passes alongside the Apple Wallet ones. Admission never depends on which wallet presented the credential; it depends on the issuing authority’s reviewed certificate.
Will it run on our existing Android handhelds?
Possibly. The verifier is hardware-neutral software, but NFC reader-mode and BLE peripheral behavior vary enough between chipsets and OEM builds that a matching spec sheet is not a substitute for a physical run. Device qualification can be scoped into a pilot.
04
Operations
What happens when the network drops?
Checks continue, because verification is local. Completed outcomes queue in a bounded durable on-device outbox and are delivered when connectivity returns. Retries are replay-safe, so aggregate counts do not double-count after a reconnection.
How long can a verifier run offline?
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.
How much training do staff need?
Three outcomes and three actions. If it took longer than that it would not survive a real shift, which is why the outcome vocabulary is deliberately closed.
How do we handle a lost or stolen device?
Revoke it in the portal. Revocation is terminal: the credential is retired and the device cannot be returned to service by reinstalling, downgrading, or re-running activation.
05
Commercial and assurance
How does a pilot work?
Thirty days at one location with two to five verifiers, including portal access, deployment support, operator training, a security and privacy review, metrics agreed in advance, a weekly review, and a rollback plan written before the pilot starts.
What does it cost?
Pilots are quoted per engagement. Locations, device count, hardware source, deployment support, and term set the number, and qualification produces the quote before you commit.
Do you hold SOC 2 or ISO 27001?
No. LaurelID holds no SOC 2, ISO 27001, or PCI attestation, has not completed an independent third-party security audit, and has no regulatory approval or government endorsement. If that changes it will appear on the trust center with the report behind it.
Can you give us an uptime figure?
No, because we have no measurement we would defend under scrutiny. The status page explains what happens to your floor during a platform incident, which is usually the more relevant question.
Question not here?
Ask it directly. We would rather answer a hard one early than have it surface during a rollout.