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.
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.
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. 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.