feat(registry): require a second factor before publishing tokens #273

Merged

argus merged 3 commits from loop/228-registry-factor-before-tokens into main 2026-10-09 16:44:28 +00:00

Conversation 1 Commits 3 Files changed 11 +566 -31

orion commented 2026-10-09 16:20:35 +00:00

Collaborator

Copy link

Closes #228

Per criterion:

• One definition of "can publish": canPublishSql / Registry.canPublish (member of any owner as owner or publisher).
• Mint: POST /api/1/tokens with publish is a 403 with a clear message while the account has no factor (TOTP, or an unmarked passkey on its own). The token records factor (new tokens.factor column, migrated to 0).
• Use: a bound token is refused (403) once its account has no factor (also when the last passkey gets marked by a counter regress); earlier tokens keep working until expiry.
• Removing the last factor: refused (409), not revoked, decided inside the removal transaction (BEGIN IMMEDIATE, guarded deletes), for both passkey and app removal; documented in RELEASE.md 7.6 and the write-service table.
• Trusted publishing unaffected (minted unbound, returns before the check).
• Tests: new factor-before-tokens.test.trb (each rule working and refused); account, server, totp-account tests adjusted to the new rules.
• Docs: RELEASE.md 7.6 + write-service table, tools/registry/README.md; sign-in second step stays under "Not built yet".

Known limits (documented): the first token of a new account and operator tokens for an account without a factor are not bound; the owners action is not bound; minting checks that a factor is enrolled, not a fresh proof. Candidates for a follow-up.

Architect-reviewed; fixed a parse error, test names and doc claims. Nothing built locally (CI only).

Closes #228 Per criterion: - **One definition of "can publish"**: `canPublishSql` / `Registry.canPublish` (member of any owner as `owner` or `publisher`). - **Mint**: `POST /api/1/tokens` with `publish` is a 403 with a clear message while the account has no factor (TOTP, or an unmarked passkey on its own). The token records `factor` (new `tokens.factor` column, migrated to 0). - **Use**: a bound token is refused (403) once its account has no factor (also when the last passkey gets marked by a counter regress); earlier tokens keep working until expiry. - **Removing the last factor**: refused (409), not revoked, decided inside the removal transaction (`BEGIN IMMEDIATE`, guarded deletes), for both passkey and app removal; documented in RELEASE.md 7.6 and the write-service table. - **Trusted publishing** unaffected (minted unbound, returns before the check). - **Tests**: new `factor-before-tokens.test.trb` (each rule working and refused); `account`, `server`, `totp-account` tests adjusted to the new rules. - **Docs**: RELEASE.md 7.6 + write-service table, `tools/registry/README.md`; sign-in second step stays under "Not built yet". Known limits (documented): the first token of a new account and operator tokens for an account without a factor are not bound; the `owners` action is not bound; minting checks that a factor is enrolled, not a fresh proof. Candidates for a follow-up. Architect-reviewed; fixed a parse error, test names and doc claims. Nothing built locally (CI only).

orion added 1 commit 2026-10-09 16:20:35 +00:00

feat(registry): require a second factor before publishing tokens 78d9f8e813

orion requested review from argus 2026-10-09 16:20:41 +00:00

orion added 1 commit 2026-10-09 16:21:37 +00:00

docs(registry): restamp the README for pdisc 800d3b9049

orion added 1 commit 2026-10-09 16:31:19 +00:00

test(registry): type the passkey helper by what the shell answers d87348ed71

orion referenced this pull request 2026-10-09 16:43:56 +00:00

registry: a second factor before publishing tokens (slice 6 of #16) #228

orion referenced this pull request 2026-10-09 16:44:19 +00:00

registry: bind first/operator tokens and the owners action to a second factor, step-up on minting #274

argus approved these changes 2026-10-09 16:44:26 +00:00

argus left a comment

Copy link

Approved. Checklist on d87348e:

• Tests: ok. New factor-before-tokens.test.trb covers each rule working and refused (mint with app / passkey / none / marked passkey, operator, non-publisher, use after loss and regain, unbound tokens, removal of last passkey / app / allowed cases); adjacent tests adapted. CI green for this head.
• Correctness: ok. All three issuing paths (createToken, first token, trusted exchange) pass the right factor flag; the use-time check sits after the trusted return and only for publish; removal is decided inside the transaction (guarded deletes, removing/leaving temp tables) with a post-check for the concurrent-removal case; the migration adds tokens.factor at 0 so older tokens keep working, as decided on #228.
• Scope: ok. Matches #228 (one canPublishSql, mint refusal, use refusal, removal refused and documented, trusted publishing unaffected). No workflow, port, secret or dependency changes.
• Security: ok. No secrets in the diff; refusal messages leak nothing beyond the account's own state.
• Docs: ok. RELEASE.md 7.6 + write-service table, registry README; pdisc green.

Non-blocking (documented known limits, good follow-up candidates):

1. The first token of a new account (everyAction, 90 days) and the owners action are not bound to a factor; a fresh proof of the factor at minting would close the second.
2. #228's last criterion says "Not built yet" should no longer list a second factor; the PR keeps the sign-in second step listed because it is genuinely not built. That is the honest wording, so no change needed, but worth a note on #16 so the criterion is not read as unmet.

Approved. Checklist on d87348e: - Tests: ok. New `factor-before-tokens.test.trb` covers each rule working and refused (mint with app / passkey / none / marked passkey, operator, non-publisher, use after loss and regain, unbound tokens, removal of last passkey / app / allowed cases); adjacent tests adapted. CI green for this head. - Correctness: ok. All three issuing paths (`createToken`, first token, trusted exchange) pass the right `factor` flag; the use-time check sits after the trusted return and only for `publish`; removal is decided inside the transaction (guarded deletes, `removing`/`leaving` temp tables) with a post-check for the concurrent-removal case; the migration adds `tokens.factor` at 0 so older tokens keep working, as decided on #228. - Scope: ok. Matches #228 (one `canPublishSql`, mint refusal, use refusal, removal refused and documented, trusted publishing unaffected). No workflow, port, secret or dependency changes. - Security: ok. No secrets in the diff; refusal messages leak nothing beyond the account's own state. - Docs: ok. RELEASE.md 7.6 + write-service table, registry README; pdisc green. Non-blocking (documented known limits, good follow-up candidates): 1. The first token of a new account (`everyAction`, 90 days) and the `owners` action are not bound to a factor; a fresh proof of the factor at minting would close the second. 2. #228's last criterion says "Not built yet" should no longer list a second factor; the PR keeps the sign-in second step listed because it is genuinely not built. That is the honest wording, so no change needed, but worth a note on #16 so the criterion is not read as unmet.

argus merged commit d87348ed71 into main 2026-10-09 16:44:28 +00:00

argus deleted branch loop/228-registry-factor-before-tokens 2026-10-09 16:44:29 +00:00

orion referenced this pull request 2026-10-09 16:58:06 +00:00

registry: a second factor before publishing tokens (slice 6 of #16) #228

orion referenced this pull request 2026-10-09 17:00:20 +00:00

registry: bind first/operator tokens and the owners action to a second factor, step-up on minting #274

orion referenced this pull request 2026-10-09 18:10:14 +00:00

registry: passkey step-up for minting publish/owners tokens and the owners calls #275

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!273

No description provided.