From c9e82e876d3789a8b870b8c59cef7e914b3eee00 Mon Sep 17 00:00:00 2001 From: Wessel Verheij Date: Sun, 13 Sep 2026 12:47:58 +0200 Subject: [PATCH] docs(f3): an account is a credential, and it is minted for nobody who can object MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit F3-R39 closed the sheet a reader mints for themselves and F3-R40 the two writes an owner makes into a partner's account. The third is one step further out again: the owner creates the account, choosing its first password, on owner authority and nothing else. Creating is not rewriting, and the argument has to be made rather than borrowed. There is no standing credential of the new account to prove knowledge of. The reader who will hold it cannot consent, because they do not exist. What is left is the owner's authority, which is what the rule has been the whole way down — so the owner's own password is the proof here too, and F3-R41 asks for it. What comes out is durable in the same way a sheet is. The owner changing their own password afterwards does not revoke the account, and unlike the partner writes nobody is signed out and puzzled, because there is nobody yet to notice. The first account on an install stays exempt, and the requirement says so rather than leaving it to be read in: there is no owner then, so there is no authority to prove and nothing to prove it with. Spec: F3-R41 Signed-off-by: Wessel Verheij --- .../features/f-platform/f3-auth-and-app-lock.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/10-functional/features/f-platform/f3-auth-and-app-lock.md b/10-functional/features/f-platform/f3-auth-and-app-lock.md index 0e03d0a..f50c535 100644 --- a/10-functional/features/f-platform/f3-auth-and-app-lock.md +++ b/10-functional/features/f-platform/f3-auth-and-app-lock.md @@ -87,6 +87,19 @@ authority. Proof matches the authority being used, not the credential being rewritten. Neither write is retired by the partner's own later password change: one *set* that password, and the other issues the codes that reset it. +**And so does an account minted for a reader who does not exist yet.** The owner +can add a household member, choosing that member's first password +([F3-R3](#acceptance-criteria)). Creating is not rewriting: there is no standing +credential to prove knowledge of, and the reader who will hold the account cannot +consent, because they do not exist. What is left is the owner's authority — which +is what the rule has been the whole way down — so the owner's own password is the +proof here too. What it produces is durable in the same way the sheet is: the +owner changing their own password afterwards does not revoke the account, and no +partner is signed out and puzzled, because there is nobody yet to notice. The +**first** account on an install is a different act and stays exempt: there is no +owner then, so there is no authority to prove and nothing to prove it with +([F3-R1](#acceptance-criteria)). + ### The app-lock A numeric code, and optionally a device biometric, gating the application @@ -215,6 +228,7 @@ needs the key that a locked session does not have. | **F3-R38** | Sign-in with the account password MUST be rate-limited. The limit MUST be counted on the username as typed and normalised, so an unknown username is metered identically to a known one and the limiter reveals nothing about which it was; it MUST be enforced in the action rather than on the route, because the credential arrives on the Livewire update endpoint that route middleware does not cover; and a successful sign-in MUST clear it. The refusal MUST NOT distinguish a throttled known username from a throttled unknown one ([F3-R13](#acceptance-criteria), [F3-R34](#acceptance-criteria)). | | **F3-R39** | Regenerating a recovery sheet for one's own account from a signed-in session MUST require the account password, not a confirmation alone. A sheet outlives the session that minted it and is not retired by a later password change, so without the password a borrowed unlocked session becomes a credential the account holder cannot revoke. The command-line path stays exempt: access to the machine is its proof ([F3-R14](#acceptance-criteria)). | | **F3-R40** | An owner acting on a partner's credentials — setting the partner's password, or minting the partner's recovery sheet — MUST require the owner's own account password. Owner-only authority is a property of the session and is carried by a session in the wrong hands, so it cannot stand as proof of the actor. The proof MUST be the owner's rather than the partner's, because the partner's credential is not available to the surface that replaces it and because the authority being exercised is the owner's. Neither write is retired by the partner's own later password change ([F3-R4](#acceptance-criteria), [F3-R35](#acceptance-criteria)). | +| **F3-R41** | Creating an additional account from a signed-in session MUST require the creating owner's own account password. There is no credential of the new account to prove knowledge of and nobody able to consent, because the reader does not exist yet; what is being exercised is the owner's authority, so the owner is who must be proved present. The account that results is durable access the owner's own later password change does not revoke. Creating the **first** account on an install MUST stay exempt: there is no owner then, so there is no authority to prove and nothing to prove it with ([F3-R1](#acceptance-criteria), [F3-R3](#acceptance-criteria)). | > **`F3-R33` landed on 2026-09-05**, the same day the deferral it was carried > under was reversed. "Registered but not yet wired" had been stale for months: