Trust center
Including the parts that are unfinished. A trust page that only lists strengths is a marketing page wearing a security page's clothes.
01 · The package
The data-flow boundary, the inbound vocabulary, and the never-collected list.
Credentials, keystore protection, issuer trust, replay defence, and tenancy.
Every record we keep, why it exists, and how long it lives.
The infrastructure providers in the path and what each one handles.
How to report a security issue, and what we commit to in return.
A one-page, printable summary for a review packet.
02 · System architecture
The public site, the operational portal, and the verifier fleet all talk to one API, which is the only writer to the database. Shared contract schemas define every boundary — including the device boundary, which is where the privacy guarantee is enforced rather than asserted.
03 · Public-site dataflows
The public site has no visitor account, analytics cookie, or hidden visitor identifier. These are the complete reviewed network flows initiated by its JavaScript.
Trigger: A visitor opens a mobile-ID support directory or state page.
Fields: registry and schema versions; public jurisdiction and wallet identifiers; closed operational support labels.
Browser policy: credentials omit; referrer no-referrer.
Client storage: Memory for the current page only; no cookie or visitor ID.
Server retention: No visitor record is created by this read.
Trigger: A visitor deliberately submits the contact or pilot form.
Fields: work email and organization; contact message, or closed pilot-qualification answers; server-generated support reference.
Browser policy: credentials omit; referrer no-referrer.
Client storage: None; the form is cleared only after an accepted response.
Server retention: Contact messages follow the customer-contact process in the transactional-email system. Pilot inquiries are staff/business records in the platform database and are subject to the documented customer-contact deletion process; they are never verification telemetry.
Trigger: A visitor deliberately registers for controlled mobile-ID qualification.
Fields: contact email and affirmative consent; public jurisdiction and wallet family; coarse device type and in-person availability.
Browser policy: credentials omit; referrer no-referrer.
Client storage: None.
Server retention: Delivered to the dedicated contact inbox under the customer-contact retention process; not inserted into platform verification or qualification tables.
Trigger: A visitor activates one of four enumerated public calls to action.
Fields: closed call-to-action type; optional public jurisdiction and wallet family.
Browser policy: credentials omit; referrer no-referrer.
Client storage: None; delivery is best-effort and has no retry identifier.
Server retention: Daily aggregate counts only. No IP address, user agent, cookie, visitor ID, event row, or contact linkage is retained.
04 · Data inventory, in one line
The full inventory — including the operational records that do exist and their retention windows — is on data and retention.
05 · Release posture
Verifier releases are signed with the permanent LaurelID certificate. Signing identity is verified as part of deployment; a build that does not match is not a LaurelID release.
Each release directory carries generated metadata — identity, size, hashes, signer, SDK values — derived from the exact validated artifact rather than hand-authored. Absence of that metadata means the candidate was never packaged.
A packaged release is not an accepted release. Acceptance requires a physical run on real hardware with a real credential. We treat packaging and acceptance as separate facts because conflating them is how fleets get hurt.
06 · Current limitations
No SOC 2, ISO 27001, or PCI attestation. No completed independent security audit. No regulatory approval or government endorsement of any kind.
The checked-in registry records physical evidence for 15 jurisdictions in both Apple Wallet and Google Wallet 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 support still requires live operational confirmation; every pair is listed with a fail-closed status on the compatibility page.
We do not publish an uptime percentage, an accuracy rate or a public status page, because we have no measurement we would defend yet. Verification does not depend on the platform: the check runs on the verifier, and during a platform incident checks continue while setup, changes and reporting wait. Incident communication is a named responsibility in every pilot agreement.
A process kill in the narrow window after a result is shown but before the outbox commit can lose that one aggregate event. Described in full on offline reliability.
We would rather your reviewer finds our limits than your rollout does.