You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-on design ticket from #5684 — its decomposition sketch names this as a separate design, and the parent's acceptance requires these tickets to be filed and linked. Filed in the 2026-11-04 gap pass (WS-F) so the design work exists and can be prioritised on its own merits; implementation timing is a separate decision, possibly months out.
What this design must settle
OIDC and username/password login with no authorizer key custody: the feasibility matrix and the constructions that could make it honest.
Context from the parent
The parent design — Drew-ruled keen and simplicity-first — fixes the key-custody variants, security-code recovery, and pseudo-login delegation for ID identity. The parent issue carries the surrounding decisions this ticket must not re-decide; where this ticket's answer would change a parent decision, record that explicitly rather than silently forking it.
Decision record expected
Close this design with a recorded decision (on this issue or in a doc/ record linked from it): the chosen shape, the alternatives rejected and why, and the invariants implementation must hold. If the design splits further, file the splits and link them here rather than growing this issue.
Relations
Parent: #5684. Programme: epic #2056. Filed by WS-F (2026-11-04 ID design gap & expansion pass).
Expectation: handed off to the opencode execution lane; the laptop claimant launches the bound opencode session, which drives task 10287 to its terminal state.
Current implementation / prior art:pkgs/id/src/directory.rs has AccountSignedUp and AccountKeyed account models, but a current pkgs/id/src search found no Google/OIDC/OAuth/WebAuthn/PAKE login implementation. The existing doc/2026-10-29T11-28-18Z_investigation_key_recovery_hosted/ (id: investigate: key recovery for hosted users — Google SSO loss vs the ID keypair #2060) is relevant prior art: it separates hosted-account SSO from identity-key custody and argues SSO must not rebind a key. It does not settle this issue's username/password and PAKE feasibility, login-method × custody matrix, or exact signed setup/hash construction, so id: design: keyless-custody login feasibility (investigation) (from #5684) #5885 is not superseded.
Activity
developing-today commentedon Nov 5, 2026
CODE-1568
developing-today commentedon Nov 5, 2026
🤖 Agent note · handed off
developing-today commentedon Nov 5, 2026
🤖 Agent note · state: handed off
115 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 6, 2026
Triage at current main (2026-11-06;
origin/maindfe3277).pkgs/id/src/directory.rshasAccountSignedUpandAccountKeyedaccount models, but a currentpkgs/id/srcsearch found no Google/OIDC/OAuth/WebAuthn/PAKE login implementation. The existingdoc/2026-10-29T11-28-18Z_investigation_key_recovery_hosted/(id: investigate: key recovery for hosted users — Google SSO loss vs the ID keypair #2060) is relevant prior art: it separates hosted-account SSO from identity-key custody and argues SSO must not rebind a key. It does not settle this issue's username/password and PAKE feasibility, login-method × custody matrix, or exact signed setup/hash construction, so id: design: keyless-custody login feasibility (investigation) (from #5684) #5885 is not superseded.Outcome: scoped and ready for design/research; no evidence of completion or supersession.
🤖 Agent note · triaged