One page, for your review packet.

1. What the product does

LaurelID verifies that a patron presenting an ISO/IEC 18013-5 mobile ID is 21 or older. The check runs on an enterprise Android verifier at the point of service. The Laurel Secure platform receives an aggregate outcome and never receives patron identity.

2. The verification request

This is the complete request, unchanged in every release. It is a minimal-disclosure request for a single pre-computed age attestation, with retention explicitly declined.

3. Data the platform never receives

• Name
• Date of birth
• Address
• Portrait or photo
• Document number
• Wallet identifier
• Mobile-ID payload
• Session transcript
• Patron identifier
• Repeat-visitor identifier

No column, blob path, or contract field exists for any of these. The device-to-platform schema is an allowlist that rejects unrecognized fields rather than stripping them.

4. What the platform does receive

Per verification event: a random event ID used only for retry de-duplication, the device and location identifiers, one of three outcomes (pass, fail, unable_to_verify), an optional closed failure category used only when the outcome is unable_to_verify, the occurrence time, the application version, and optionally the configuration version. There is no other legal field.

5. Storage and reporting

Outcomes are stored as cumulative and day-bucketed counters per location. There is no per-verification row at any tier and no patron entity in the schema. Rows below a minimum group size of k = 3 are suppressed in the database query and re-checked in API responses, exports, and contracts, for every role including the highest.

6. Device security

Devices are created in the portal and activated with a single-use code. The device credential is encrypted under the Android Keystore, using StrongBox where the hardware provides it, with an explicit guarded fallback where it does not. Credentials rotate with a bounded overlap and durable acknowledgement before retirement. Lifecycle policy is versioned and leased, covering active, suspended, quarantined, and revoked states; queue-delivery permission is explicit and independent. Minimum and recommended application versions are enforced by the platform. An activated device cannot be reassigned in place.

7. Issuer trust

Production trust is limited to exact certificate bytes authenticated through either the signed AAMVA Digital Trust Service VICAL or a reviewed issuing authority's official certificate endpoint. VICAL updates are verified for COSE signature, provider chain, validity interval, and rollback before atomic activation; direct pins are certificate- and jurisdiction-bound. Offline verification remains available only while both the device policy lease and the admitted signed trust publication are valid. The verifier fails closed when either boundary is reached. Android system and user CAs, credential-provided roots, imported roots, test IACAs, and indefinitely stale packages are not accepted.

8. Delivery and replay

Verification is local, so a network outage does not stop checks. Completed outcomes enter a bounded transactional on-device outbox (5,000 rows, 8 MiB, 28 days) and are delivered at-least-once. Each event carries a stable random identity that survives retry, process death, force-stop, reboot, and partial synchronization. The platform claims that identity atomically before updating a counter, so an exact retry is idempotent and a changed-payload replay fails closed. The net property is effective exactly-once aggregate effects — not a claim of exactly-once network delivery.

9. Platform architecture

One API is the only writer to the database and the only endpoint devices contact. Organization scope is applied in the database query rather than as an application-layer filter. Portal authentication runs through WorkOS AuthKit. Error reporting excludes raw request bodies and unvalidated fields, and issues are grouped and titled from bounded values rather than raw messages. Schema changes ship as reviewed, ordered migrations with a documented rollback path.

10. Subprocessors

Cloudflare (edge compute and static hosting), Neon (managed Postgres), WorkOS (portal authentication), Resend (transactional email), Sentry (error monitoring). None receives patron identity data, because the platform never receives it. This website runs no analytics, advertising, or session-replay tooling.

11. Current validation status

Checked-in evidence records 15 jurisdictions in both Apple Wallet and Google Wallet as physically validated on Elo M51. 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 is shown only after matching live operational confirmation. Without it, every combination remains fail-closed as in qualification, wallet available, planned, suspended, or unavailable.

12. Stated limitations

• No SOC 2, ISO 27001, or PCI attestation
• No completed independent third-party security audit
• No regulatory approval or government endorsement
• No published uptime or accuracy figure
• Arkansas is physically qualified in Apple Wallet and Google Wallet, but official issuing-authority certificate binding remains pending; it is not production enabled.
• No claim of perfect presentation-attack detection

One known reporting edge case: a process kill in the narrow interval after a result is rendered but before the outbox commit can lose that single aggregate event. Verification itself is unaffected; every event that reports queued is durable.

13. Reporting a security issue

Use the contact form at laurelsecure.com/contact with the subject “Security disclosure.” Do not include real personal data in a report. Full process: laurelsecure.com/trust-center/responsible-disclosure.