Trust & transparency
Identity-grade enforcement
without identity-grade liability.
lemma.id is a personal data minimizer — not a neutral pipe and not a surveillance network. We hold the minimum derived identifiers needed to make bans stick; your site holds an opaque per-site ID; users carry signed credentials in their browser wallet. Everyone knows what each party stores, processes, and never sees.
Data footprint
What each party actually holds
The privacy win is practical and bounded: relying sites avoid becoming KYC operators, users avoid a reusable global ID, and lemma.id stores derived anchors — not raw government documents.
Verdict + site-private PPID
A boolean human signal and an opaque per-site identifier like did:lemma:ppid_…. No ID document, selfie, legal name, or date of birth.
Derived identity anchors
Encrypted hashes derived from IDV outcomes, plus wallet↔person linkage for revocation. No raw documents, face images, or legal name at rest.
Email, name, login graph
Auth0, Google, and Okta typically store email, profile attributes, session history, and a shared sub across every app on that provider.
Documents + biometrics
Running Stripe Identity or Onfido yourself means your servers (or your vendor contract) hold document images, selfies, legal name, DOB, and verification reports.
Side-by-side
How lemma.id compares
Figures are directional engineering comparisons, not legal guarantees. Map to your DPIA, DPAs, and threat model before production reliance.
Honest scope
What “personal data minimizer” means here
Under GDPR, pseudonymous data is still personal data if a party holding keying material can re-identify it. lemma.id does not claim to be outside privacy law. We are a personal data minimizer for the identity-anchoring layer — deliberately holding the minimum derived identifiers needed for enforcement while meeting data-controller obligations transparently.
What lemma.id processes once (transiently, not persisted raw): document number and date of birth from the IDV provider, used only to derive cryptographic anchors. Legal name and selfie images are not used in root derivation and are not stored.
What lemma.id persists: HMAC-derived document and person-root hashes (encrypted at rest), wallet↔person bindings, per-site PPID mappings for revocation, and verification metadata. This is roughly 200 bytes of derived identifiers per person — not a document vault.
What lemma.id does not expose to sites: cross-site linkage. Sites receive only their own PPID. Lemma can correlate identities internally on the enforcement plane (revocation) — by design, so network-wide bans work — but that linkage is never returned to relying sites.
No advertising to end users: lemma.id does not use verification outcomes, credentials, wallet data, or PPIDs to advertise to people who verify through Lemma-powered sites. We do not monetize end-user identity data through ad targeting — on lemma.id or elsewhere. Product analytics and fraud prevention are separate from marketing; developer accounts may still receive service communications under our privacy policy.
lemma.id is not pretending the control plane disappears. Issuance, revocation, and recovery need infrastructure. The trust claim is narrower: routine access decisions do not require a live callback to an IDV provider, and credentials do not carry one stable cross-site identifier.
The name is the model
Why “lemma.id”
In mathematics, a lemma is a proven intermediate result — something already established that you reuse to prove a larger claim. lemma.id is short for lemma identifier: one place where you keep verified proofs of whatever claims a relying site needs — that you are human, that you meet an age threshold, that you are one account per person, and more over time.
Each proof is a signed credential stored in your browser wallet under your lemma.id. Sites do not receive your identity profile; they receive a proof of the specific claim they asked for, bound to a site-private identifier. Return visits can verify that proof locally — without a live callback and without exposing one reusable ID across the web.
Multiple different proofs under one lemma.id is itself the trust model. Verification composes: each new claim builds on anchors already proven, without turning every website into a KYC operator or building a cross-site surveillance graph. The name is not wordplay — it describes how bounded, reusable proofs build trust on the open web.
Three-party trust
How bounded data handling improves trust
For users
You verify once and carry a signed credential in your browser wallet — like a physical ID you control. Sites see a site-private pseudonym, not your name or document. Return visits verify locally; lemma.id does not observe every check. Lemma does not use your verification data to advertise to you. You can export your wallet and request erasure.
For integrators
You get an enforcement-grade human signal without building a KYC stack or holding document images. Your breach surface is an opaque PPID, not a passport scan. Compliance reviewers can see exactly what your servers store — and what they do not.
For the public web
The default choice has been “no real accountability” or “centralized identity surveillance.” lemma.id offers a third path: verified-person enforcement with site-private identifiers and local verification — accountability without asking every website to become a regulated identity operator.
Who sees what at runtime
Enforcement you can explain to legal
Add identity-rooted bot defense without turning your backend into an identity honeypot. Read the integration docs or review the full privacy policy.