amadan
spec: passkey step-up via fresh Keymail auth — a stolen session should not be enough
Approved 2026-08-02. Membership says who you are, not whether you are here now. Fresh Keymail authentication rather than console-native WebAuthn: keymail already requires user verification, and identity belongs in one place. Scope is CLI approval + destructive actions, deliberately excluding promote/rollback which already need the release key.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 file changed,
+28
−0
docs/superpowers/specs/2026-08-02-multi-account-design.md+28 −0
diff --git a/docs/superpowers/specs/2026-08-02-multi-account-design.md b/docs/superpowers/specs/2026-08-02-multi-account-design.md| index 3cc0ae6db..76295cc8d 100644 |
| --- a/docs/superpowers/specs/2026-08-02-multi-account-design.md |
| +++ b/docs/superpowers/specs/2026-08-02-multi-account-design.md |
| @@ -243,6 +243,34 @@ domains shipped inert. |
| 5. Enable `PLATFORM_APPS_DOMAIN` on the flagship. |
| 6. Woodstar migrates as the first app *born* into its own account. |
| +## 7a. Passkey step-up for sensitive actions (approved 2026-08-02) |
| + |
| +Membership authorization answers *who you are*; it does not answer *are |
| +you here right now*. A stolen session cookie is currently enough to |
| +approve a CLI login, remove a member, or delete an account. |
| + |
| +**Sensitive actions require a fresh authenticator gesture.** The route is |
| +**fresh Keymail authentication**, not console-native WebAuthn: Keymail |
| +already performs WebAuthn with `UserVerification: VerificationRequired`, |
| +and identity belongs in one place per this platform's design — a console |
| +that stored its own credentials would be a second identity system with a |
| +second attack surface. The missing piece is a way for a client to |
| +*demand* re-authentication: Keymail's OAuth needs `prompt=login` / |
| +`max_age` support, which benefits every Keymail OAuth consumer, not just |
| +this console. |
| + |
| +**The step-up set**: approving a `carlos auth login` device grant, |
| +removing a member, transferring ownership, deleting an account, revoking |
| +CLI tokens. Deliberately **not** promote/rollback — those already require |
| +the release signing key, and a passkey touch on every promotion would be |
| +felt daily for little gain. |
| + |
| +Honest trade-off: step-up depends on the identity provider supporting it. |
| +Console-native WebAuthn would bind the assertion to the console's own |
| +origin (marginally stronger against relay) and would let the platform |
| +stand alone without Keymail — it stays a named alternative if the |
| +platform ever needs IdP independence. |
| + |
| ## 8. Future work (named, not built) |
| - **Roles beyond owner/member** — read-only members, deploy-but-not-invite. |