Claiming: sign in with a passkey, publish a token, be verified

[HarryCordewener]

Stacked on #11. Spec §8 rewritten around one decision — sign in first, then claim — and built end to end.

The decision that shapes everything

The token cannot be a secret, because we ask operators to publish it on a connect screen or in an MSSP field, where every anonymous connection reads it — including every other crawler. So a bearer model, where holding the token confers the claim, is broken the instant it succeeds.

It is a nonce. It proves somebody with write access to that server published it; the account it is bound to answers who asked. Mallory reads Alice's token off the connect screen and can do nothing with it — there is a test named for exactly that.

That also answers what happens between minting and verifying: nothing needs writing down. The pending claim is durable server-side state, shown for as long as it is pending, with each channel's line ready to copy. IssueAsync returns the existing token rather than replacing it, so a refresh cannot invalidate what an operator has just finished pasting into mush.cnf.

Sign-in is passkeys and nothing else

No passwords, no email, no federated provider. The usual blocker for passwordless is account recovery, and it does not apply here: the root of trust is the server the operator controls, not the credential. Lose every device, publish a fresh token, done. An account is correspondingly worth almost nothing to steal.

Identity runs over Dapper, not EF Core — IUserStore + IUserPasskeyStore is a page of SQL, and migrations/0007_ownership.sql stays the single description of these tables. IUserPasswordStore, IUserEmailStore, lockout and two-factor are deliberately unimplemented: each absent interface is a feature we do not have, and adding the password store would make UserManager start offering flows this site has no pages for.

One script file, and it is the only JavaScript on this site. navigator.credentials has no scripting-off path, so the boundary is drawn at sign-in; the catalogue, game pages, archive, plain mode and API all keep working with scripting disabled.

Rules with teeth

• Presence establishes, absence never revokes (§8.4). Two timestamps, because they are two facts. Absence-revokes hands revocation to any transient failure — this project has watched MCCP swallow a connection's payload whole.
• Three guarantees live in the schema, not a handler: a claim carries a NOT NULL account; one account holds at most one pending claim per game (partial index, so a verified or revoked claim does not lock an account out of a game it can still prove control of); a token is unique table-wide, without which one game's published token could complete another's.
• DNS TXT is deferred, and not for want of a resolver: it proves control of a hostname, and MU* hosting routinely puts many unrelated games on one domain separated only by port. The host's operator could claim all of them.
• Accounts exist only with a database. The claim surfaces are absent rather than broken over the demo fixture — half a flow over invented games would have an operator publishing a token for a listing that is not their game.

Two gaps closed rather than worked around

IGameQueries had no by-id lookup, so an owner page had to reach past the interface or resolve a slug it was never given — a claim binds to the game, not to a name a rename can move. And the test harness had never rendered a whole page; Render.PageAsync wires the fixture and deliberately not the account services, which is the condition every claim-surface test is about.

Verified against a real database

Migration 0007 applies; /account/sign-in, /g/{slug}/claim and /account all answer; the game page offers the claim only when there is somewhere to put it; the assertion endpoint returns a real WebAuthn challenge.

Five suites, 652 tests, zero warnings.

Known and deliberate

Passkeys:ServerDomain is unset in development, so the RP ID falls back to the host. It must be configured before deployment — a passkey is bound to a domain, which gives §15.1's open domain question a deadline: credentials registered before the domain settles have to be registered again after it moves.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NrGKmKcRCGktyhRTFbQDMk

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2c687ee9-7e8d-43c3-89f4-683d2577b015

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}