lemma.id
Session Checking…

lemma.id demo

One lemma.id. A different private ID on every site.

Three concepts: Create a passkey-protected lemma.id on your device, Verify it on demo sites to mint unlinkable private IDs, then Enforce site policy, set assurance, doubt a user, or ban a PPID. Credentials stay on your device; sites verify proofs offline.

View developer docs

Stuck or mixing old state? Use Clear demo data above, close demo site tabs, then start again.

1

Create your lemma.id

Your lemma.id is passkey-protected on this device. Continuity means the same lemma.id is back, not a unique human. Sites ask it for signed presentations at whatever assurance level their policy requires.

Passkey On this device
Not created

Passkeys and seeds never leave your device. Routine site checks run locally; lemma.id does not observe your browsing on relying sites.

2

Verify on demo sites

Each site declares the assurance it requires. Your lemma.id mints a site-private proof and the site verifies it offline. Same wallet, different private ID on every hostname.

SaaS trial demo site

Pending
Private site ID ppid_trials_••••
Assurance ,
Reason ,
Latency ,
Open trials demo →

Same lemma.id. Different private IDs.

Ticketing and Trials receive different identifiers, even though both proofs come from the same lemma.id.

Ticketing ,
Verify both sites
Trials ,

Presence High-value actions can require a fresh passkey when the presentation is signed, see the presale demo for action stamps.

Developer view: signed presentations

Each site receives a signed presentation your backend verifies offline, not government ID, email, or cross-site identifiers.

Verify both sites to inspect their presentations here.

Walk presale code demo Open trials demo site
3

Enforce

Each site decides on its private ID, doubt for a fresh proof, or ban. Scoped per site: action on presale does not affect SaaS trial.

Presale , Not verified
SaaS trial , Not verified

Verify both sites above, then enforce on a row.

Set assurance level (presale)

Require human proof on presale. Same PPID after step-up, only the assurance tier changes.

Create · Verify · Enforce

Create

A passkey-protected lemma.id on your device. Continuity only at first, not a document vault, not proof of unique humanness.

Verify

Same lemma.id, different private ID per site. Signed presentations your backend verifies offline, unlinkable across relying parties.

Enforce

Set assurance, doubt a user, or ban a PPID. When abuse matters, require human proof, the private ID stays the same and the ban sticks.

Developer friendly

Simple SDK, offline verification, and site-scoped controls built for real-world abuse.

Developer view: operator tools & integrator reference

Manual verification, admin-gated SiteDoubt step-up, ops smoke checks, and operator debug. The main demo flow above covers the product story; this panel is for integration testing.

Manual site verification

Verify one site at a time or both together without leaving the hub.

Admin: legacy SiteDoubt step-up

Creates a SiteDoubt row via admin token. The main flow uses /api/demo/ishuman/site-doubt and client-side policy toggles instead.

Raise ticketing policy

Complete step-up

Relying-site demos

Reserve a ticket or start a trial on separate origins. Each site verifies the signed presentation on its own backend.

Walk presale defenses Open trials demo

Reset demo

Clear your lemma.id and demo caches so you can run the full flow again from a clean state.

Operations Check

Run the full lemma.id lifecycle and see pass/fail evidence for each operation. Passkey and IDV steps require manual interaction in this browser.

Not run 
    {}

    Three levels of proof

    lemma.id passkey

    • Continuity: same lemma.id, site-private PPID.
    • Fast unlock; no IDV required.
    • Not Sybil-resistant alone, anyone can create another lemma.id.

    Presence proof

    • Fresh passkey when the presentation is signed.
    • Shows the holder is at the device right now.
    • Still not “one human”, use a human proof for that.

    Human proof ishuman

    • Enforcement: one verified human per account.
    • Same PPID. The proof level changes, not the account.
    • Completed via IDV when site policy demands it.

    Integration snippet

    Start with lemma.id continuity; raise to a human proof only when your site policy requires one verified human. Presence is the fresh-passkey ceremony on the presentation.

    <script src="https://lemma.id/sdk/proof-verifier.js"></script> const { ok, ppid, assurance, presentation } = await new ProofVerifier({ siteId: 'tickets-demo.lemma.id', autoProvision: true, requiredAssurance: 'passkey', }).verifyForBackend({ requiredAssurance: 'passkey' }); // Human proof step-up: requiredAssurance: 'ishuman', same ppid, assurance: ishuman

    Last verify: ,

    Operator console

    Server enforcement,
    {}