Session Checking…

lemma.id demo

One lemma.id. Enforce one person per site.

Create a passkey-protected lemma.id on your device. Enforce one-human policy: one code per person, bans that stick, human proof when Sybil matters. Sign in on demo sites and get a different private ID on each hostname. Sites can't link them. Proofs stay on your device; sites verify 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

Sign in on the demo sites

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

Presale code demo

Pending
What this site sees did:lemma:ppid_ticketing_••••
Proof level -
Status -
Latency -
Open live site (optional) →

SaaS trial demo site

Pending
What this site sees did:lemma:ppid_trials_••••
Proof level -
Status -
Latency -
Open live site (optional) →

These sites can't compare notes about you.

Same lemma.id signed in on both demos. Each site sees a different private ID.

Tickets sees -
Sign in on both sites
Trials sees -

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.

Sign in on both sites to inspect their presentations here.

3

Enforce

Put on the site-owner hat. Each site decides: require human proof, doubt for a fresh check, or ban. Action on presale does not affect SaaS trial.

Presale - Not verified
SaaS trial - Not verified

Sign in on both sites above, then enforce on a row.

Stuck banned?

Set assurance level (presale)

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

What next?

For site operators

Require human proof, doubt a user, or ban, scoped per site.

For everyone

Create your passkey-protected lemma.id and use it across the web.

Create · Enforce · Sign in

Create

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

Sign in

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

Sign in on one site at a time or both together. Each site opens a short popup on its own origin, then returns the result here.

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.

Open live tickets (optional) Open live trials (optional)

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: 'lemma-demo-tickets-1d3d7411af33.herokuapp.com', autoProvision: true, requiredAssurance: 'passkey', }).verifyForBackend({ requiredAssurance: 'passkey' }); // Human proof step-up: requiredAssurance: 'ishuman', same ppid, assurance: ishuman

    Last verify: -

    Operator console

    Server enforcement-
    {}