Skip to content

Commit 3ad35d9

Browse files
author
Pulkit Pareek
committed
Add live Continue-with-ZeroAuth demo at /try + Sign-in-with-ZeroAuth plan
/try is a premium, generic 'Continue with ZeroAuth' demo that drives the SAME proven live /api/demo-portal/* flow as the bank demo (real init-login + QR + SSE + claim sign-in, and real three-QR account creation) — framed as a universal Sign-in-with-ZeroAuth for any site. Served same-origin with the apex API so the desktop cookie + SSE handshake works. Also lands docs/plan/sign-in-with-zeroauth/ — the full architecture + roadmap + accelerator pitch/demo blueprint for the universal IdP.
1 parent fe795ed commit 3ad35d9

11 files changed

Lines changed: 2037 additions & 0 deletions

File tree

‎demo-portal/public/try.html‎

Lines changed: 294 additions & 0 deletions
Large diffs are not rendered by default.

‎docs/plan/sign-in-with-zeroauth/00-README.md‎

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
# Sign in with ZeroAuth — universal passwordless identity
2+
3+
> **Status:** Plan / pre-implementation. This is a planning document set, not
4+
> shipped architecture. Where it says "today" it describes the current
5+
> codebase; everything else is proposed.
6+
>
7+
> **One-liner:** Turn ZeroAuth from a per-customer biometric auth layer into a
8+
> portable, self-sovereign identity that replaces passwords across every
9+
> website — "Sign in with ZeroAuth."
10+
11+
---
12+
13+
## The idea
14+
15+
Every consumer installs the ZeroAuth app once and enrolls **one identity**:
16+
their face (held on-device as a secret) plus basic verified attributes (name,
17+
email, phone). From then on:
18+
19+
- **Create an account anywhere** (YouTube, a bank, a store): the website asks
20+
for whatever it needs, the user fills the required fields — auto-filled from
21+
their on-phone identity where possible — then scans a QR and confirms with
22+
their face on the phone. Account created. No password ever set.
23+
- **Sign in anywhere:** the user enters their email/handle, the site shows a
24+
QR, the user confirms on the phone. Signed in. No password ever typed.
25+
- **"Already exists / doesn't exist"** is answered by the *website*, not by
26+
ZeroAuth — the site checks whether the presented identity is already in its
27+
own users table and routes the user to sign-in vs sign-up accordingly.
28+
29+
The person is the credential. Passwords disappear.
30+
31+
## How this differs from what exists today
32+
33+
Today ZeroAuth is a **per-tenant** biometric auth product: each customer
34+
(e.g. the Anchor Bank / NeoBank demo) is a tenant, and a user registers
35+
*separately* per tenant. The hosted bank demo
36+
([docs/plan/bfsi-v1](../bfsi-v1/00-README.md)) is, in effect, a single-site
37+
instance of this larger idea.
38+
39+
"Sign in with ZeroAuth" generalizes that to a **multi–relying-party identity
40+
network**: one on-phone identity, reused across many independent websites,
41+
with cross-site privacy by construction.
42+
43+
| | Bank demo (today) | Sign in with ZeroAuth (this plan) |
44+
|---|---|---|
45+
| Identity scope | Per tenant | One identity, many relying parties |
46+
| DID | Global (same on every site) | **Pairwise** (unlinkable per site) |
47+
| Attributes | None | Verified name/email/phone, selectively disclosed |
48+
| "Account exists?" | N/A | Relying party checks its own table |
49+
| Recovery | Deferred TODO | **First-class, load-bearing** |
50+
| Integration | Hardcoded demo bridge | Public SDK + OIDC bridge |
51+
52+
## Scope
53+
54+
**In scope (this plan):**
55+
56+
1. A **relying-party (RP) model** — any website integrates "Sign in with
57+
ZeroAuth" with a console-minted API key + a drop-in SDK.
58+
2. **Pairwise DIDs** so a user is consistent within a site but unlinkable
59+
across sites.
60+
3. **Verifiable attributes** — name/email/phone enrolled + verified once,
61+
then selectively disclosed to RPs at signup.
62+
4. **Account-existence routing** owned by the RP ("already exists → sign in").
63+
5. **Recovery** — lost phone / new phone must not mean losing every account.
64+
6. **Developer surface** — SDK, OIDC bridge, self-serve onboarding, docs.
65+
66+
**Out of scope (explicit non-goals):**
67+
68+
- ZeroAuth becoming a data broker. We never build a profile of which sites a
69+
user belongs to. (See Principle 2.)
70+
- Replacing the RP's own authorization/session logic. We assert *identity*;
71+
the RP still owns roles, sessions, and access control.
72+
- Custodying user funds, documents, or government-ID issuance. ZeroAuth
73+
verifies presence + attribute possession, not statehood.
74+
- Inventing new cryptography where a reviewed standard exists. Prefer
75+
Groth16/Poseidon (already in use), BIP39, BBS+/AnonCreds, OIDC, FIDO2.
76+
77+
## Guiding principles (the standing constraints)
78+
79+
These are load-bearing. Every design decision and PR in this initiative must
80+
hold all of them.
81+
82+
1. **The biometric never leaves the device.** Unchanged from the platform
83+
non-goals — the wire carries proofs + commitments + signatures only.
84+
2. **ZeroAuth never learns the user's site graph.** No server-side mapping of
85+
"DID → which relying parties." Account existence is the RP's question,
86+
answered against the RP's own data. A ZeroAuth breach must not reveal who
87+
uses what.
88+
3. **Pairwise by default.** A user presents a *different* DID to every RP.
89+
Cross-site linkage is opt-in (e.g. the user explicitly links two accounts),
90+
never the default.
91+
4. **The relying party owns the account.** ZeroAuth provides a verified
92+
identity assertion; the RP decides what to do with it (create, match, deny).
93+
5. **Recovery is a feature, not an afterthought.** No flow ships until its
94+
recovery path ships. Losing a phone cannot mean losing one's digital life.
95+
6. **Attributes are verifiable and minimal.** RPs receive the least they need,
96+
with proof of verification, never raw ZeroAuth-held PII dumps.
97+
7. **No vendor in the middle.** Unlike platform passkeys, the identity is not
98+
custodied by Apple/Google. ZeroAuth is a verifier/coordinator, not an owner.
99+
8. **Standards-aligned at the edges.** Offer an OIDC "Sign in with ZeroAuth"
100+
button so RPs integrate with zero new concepts; interoperate with FIDO2
101+
where it helps rather than competing head-on.
102+
9. **Assurance is explicit.** Every assertion carries an assurance level
103+
(presence-only vs liveness-verified vs attribute-verified), so RPs choose
104+
the bar they need (cf. NIST IAL/AAL).
105+
10. **Every RP/identity action is audited** in a tamper-evident log, scoped so
106+
the audit itself doesn't become a cross-site correlation oracle.
107+
108+
## Phase map
109+
110+
Detailed in [05-roadmap.md](05-roadmap.md). At a glance:
111+
112+
- **P0 — Foundations.** Generalize the tenant model into relying parties;
113+
pairwise DIDs; SDK MVP; the generalized register/sign-in flow (closes the
114+
demo-only "peek" gap from the bank demo).
115+
- **P1 — Verified attributes.** Email/phone OTP at enrollment; verifiable
116+
credential issuance; selective disclosure to RPs at signup.
117+
- **P2 — Recovery.** Recovery phrase + multi-device enrollment; the
118+
"new phone, same identity" path.
119+
- **P3 — Developer platform.** OIDC bridge; self-serve RP onboarding in the
120+
console; quotas, analytics, docs.
121+
- **P4 — Advanced.** Fuzzy-extractor (face-as-key cross-device), social /
122+
guardian recovery, scale + assurance-level certification.
123+
124+
## Document map
125+
126+
| Doc | What it covers |
127+
|---|---|
128+
| [01-architecture.md](01-architecture.md) | The load-bearing decisions + actors + trust model |
129+
| [02-flows.md](02-flows.md) | Every user journey as a concrete protocol flow |
130+
| [03-api-and-sdk.md](03-api-and-sdk.md) | Endpoints, the RP SDK, the OIDC bridge |
131+
| [04-recovery.md](04-recovery.md) | The recovery model in depth (the make-or-break) |
132+
| [05-roadmap.md](05-roadmap.md) | Phased milestones, exit gates, code mapping |
133+
| [06-threat-model-and-positioning.md](06-threat-model-and-positioning.md) | New threats + honest competitive positioning |
134+
135+
## Glossary
136+
137+
- **Holder** — the user + their phone, which holds the master secret and
138+
attributes.
139+
- **Relying Party (RP)** — a website/app that integrates "Sign in with
140+
ZeroAuth" to authenticate its users. Each RP is a ZeroAuth tenant.
141+
- **Verifier / Coordinator** — the ZeroAuth backend: mints session
142+
challenges, verifies ZK proofs, anchors RP-scoped commitments, attests
143+
attributes. It is *not* an identity owner.
144+
- **DID** — decentralized identifier. Today `did:zeroauth:face:<suffix>`.
145+
- **Pairwise DID** — a per-RP DID derived deterministically from the master
146+
secret + the RP's identifier, so the same person is unlinkable across RPs.
147+
- **Master secret** — the on-device root secret (today derived from the face
148+
template) from which pairwise DIDs and commitments are derived.
149+
- **Verifiable Credential (VC)** — a signed attribute the holder can present +
150+
prove without the verifier re-checking the source (e.g. "email verified").
151+
- **Selective disclosure** — revealing only the attributes an RP needs (and
152+
sometimes only a predicate, e.g. "over 18") rather than the full set.
153+
- **Assurance level** — how strongly an assertion is backed (presence,
154+
liveness, attribute-verified). Mirrors NIST 800-63 IAL/AAL.
155+
156+
---
157+
158+
LAST_UPDATED: 2026-06-05
159+
OWNER: Pulkit Pareek (engineering) + Amit Dua (product)
160+
STATUS: Draft plan — pending review + ADR ratification of the core decisions in 01-architecture.md

0 commit comments

Comments
 (0)