carlos / platform Public

console: passkey step-up for sensitive actions, and account deletion that sticks (#7)

* console: passkey step-up for sensitive actions — membership says who you are, not that you are here

Spec §7a. A session cookie lifted from a laptop is currently enough to approve
a `carlos auth login` device grant, remove a member, or revoke somebody's
terminals. Membership answers "who is this?"; nothing here answered "are they
still at the keyboard?".

The route is a fresh Keymail authentication (keymail PR #149: prompt=login,
max_age, auth_time), not console-native WebAuthn — identity stays in one place
per this platform's design.

- stepup.go: requireFreshAuth. Reads database state written only by a verified
  callback, so the gate is UNSKIPPABLE server-side: a direct POST with a good
  session and a good CSRF token is refused all the same. The interrupted action
  is preserved so a human is not dumped back at square one, but it is held
  SERVER-SIDE, bound to the session that stashed it, single-use by row deletion
  and short-lived; the browser carries an opaque token in an HttpOnly cookie and
  nothing else, so it cannot swap the action or replay it. The csrf field is
  deliberately not stored — sessions are kept hashed here, and a form blob is no
  exemption; the resume re-injects it from the browser's own cookie.
- Freshness window: 5 minutes, measured from Keymail's auth_time (the gesture),
  never from when the console heard about it.
- Gated: approving a device grant, revoking a CLI token, removing a member,
  transferring ownership, deleting an account. NOT promote/rollback — those
  already need the release signing key, and a daily passkey touch buys little.
  Denying a device grant stays ungated: it is the panic button and only ever
  destroys a pending request.
- ownership.go: the three owner actions §7a names but that had no HTTP handler
  at all. Deletion is narrow on purpose — an account still holding apps is
  refused rather than cascading into objects, routes and domains nobody can
  restore.
- FAILS CLOSED, every path: Keymail unreachable, a deployment that does not
  advertise re-authentication, a grant with no auth_time, a stale auth_time, or
  a gesture from a different Keymail address — all refuse, none downgrade to
  session-only.
- The byte-identical 404 survives: step-up runs AFTER the ownership gate, so a
  non-member never sees a redirect that would confirm the account exists, and
  never parks a pending action. CSRF is unchanged and still runs first.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* console: deleting an account is a tombstone in the bucket, not rows in a console

DeleteAccount emptied this console's tables and nothing else. Account
identity lives at accounts/<sqid>/account.json, and every console start
materializes from it, so the account came back on the next deploy — with
the owner membership the manifest names, which after an ownership
transfer is not the person who deleted it. The operator saw "Deleted X"
and X returned.

The manifest is now tombstoned with deleted_at rather than removed: the
id stays spent, because NextAccountID takes one past the highest id any
manifest claims and a reused id is a reused sqid — a hostname already
published in Certificate Transparency and cached in DNS. owner is
cleared so a consumer that has never heard of deleted_at at worst
materializes something nobody holds.

Every consumer that materializes the manifest skips a tombstone
(console.MaterializeAccounts, domains.Reconcile, which also drops the
registry row so the deletion reaches every box, not just the console
that performed it); NextAccountID still counts it. The bucket write
happens first and a failure abandons the deletion — a console with no
release store now refuses rather than deleting locally.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>