Repository navigation
id: investigate: key recovery for hosted users — Google SSO loss vs the ID keypair #2060
Description
Source: the Cloudflare Workers fit investigation (on #2044) open question 4. SSO binds a Google identity to an account, but the ID keypair IS the identity, and custodial server-held keys are rejected (they break the LIST 7 trust model). Investigate recovery paths: lost Google account, lost device/key, multi-device and social recovery — without the server ever holding keys.
Program: Drew's 2026-10-28 directive (full text: hatch-personal memory/topics/id-program-2026-10-28.md). Parent epic: #2056.
Working pattern: parallel investigations, then the named synthesis issue merges them into a full design. Route guidance: Workhorse by default; Specialist/Summit for synthesis and ramification-heavy work. A result that says "done" is not the endpoint — the orchestrator reviews it and may commission another round. Deliverables: a markdown design/investigation doc (mermaid/SVG diagrams welcome) linked from this issue, plus follow-up issues for anything buildable. Build a proof of concept where the design calls for one, but do NOT build the permanent feature on top of an unreviewed PoC.
Acceptance criteria
- A markdown investigation doc is linked from this issue covering recovery paths for: lost Google account, lost device/key, multi-device use, and social recovery.
- Every proposed path preserves the constraint that the server never holds user keys (custodial keys are rejected — they break the LIST 7 trust model).
- The doc ends with a recommended recovery model for the hosted edition, or states explicitly which cases remain unsolved and why.
- Anything buildable that falls out is filed as follow-up issues linked here.
Activity
dezren39 commentedon Oct 29, 2026
Parent epic: #2056 — ID platform expansion (2026-10-28 directive). Filed as batch 2 from PREPARED-ACTIONS.md.
developing-today commentedon Oct 29, 2026
CODE-981
dezren39 commentedon Oct 29, 2026
Intake review
Related: parent epic #2056; source: Workers fit investigation #2044, open question 4; sibling investigations #2059 and #2061.
Notes: the tension is the point of this one — SSO recovery expectations vs the keypair-is-identity model; the doc should not paper over the unsolved cases.
Risks: social/multi-device recovery schemes can quietly reintroduce custodial trust; each path needs its trust assumptions stated.
Suggested approach: Workhorse investigation; Specialist review if a novel recovery scheme is proposed.
— Fleet monitor intake pass (protocol §5): issue verified still live this run (filed within the last hour; no merged PR or duplicate resolves it), labels normalized, meta/enriched applied.
dezren39 commentedon Oct 29, 2026
Top priority — ID program wave-1. Drew directed this be picked up in the next runs (2026-10-29): enqueued directly as triage task 3362 in repo-health-code-pilot at queue priority 20 (only breakage-class work at priority 10 outranks it). Wave-1 is the ungated investigations and designs; syntheses and PoCs stay gated on their named inputs. Investigation route: Workhorse.
100 remaining items
dezren39 commentedon Oct 29, 2026
agent-note:v1 — correction from repo-queue worker lane A (task 3362): the park in the previous note did NOT take effect — the queue returned "task 3362 is not claimed by repo-worker-code" for both the checkpoint and the park (the claim lease was lost mid-shift), and labels have been reset to queue/queued accordingly. The substantive finding stands and is queue-independent: PR #2278 is in the merge queue at position 5, AWAITING_CHECKS, all 8 Codex threads resolved. Whoever claims task 3362 next: verify PR #2278 merged → tick acceptance → complete as triaged.
dezren39 commentedon Oct 29, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 29, 2026
🤖 Agent note · done
investigations/key-recovery.mdin the ID program workspace (local copy, landing in-repo via the program docs PR like id: investigate: TigerBeetle — multi-currency ledgers, conversions, per-coin vs balance model, 3-node cluster topology #2040/id: investigate: Cloudflare Workers edition — isolates + Durable Objects + per-user SQLite fit for ID #2044).Verdict: every case is solvable except total unprepared loss (only key, no second device, no backup, no guardians) — unrecoverable by mathematics, since any mechanism that recovered it would be a backdoor. The enabling move: treat the account as a signed keyset/authorization log (device keys, revocation, IdP bindings, guardian sets, rotations as public signed records) instead of one key — the server stores public records and ciphertext only, never secrets.
Sessionper device and has arecoverop.Follow-ups filed: #2380 (keyset/authorization log), #2381 (encrypted backup: seed + passphrase-wrapped), #2382 (guardian social recovery).