docs(design): state the node-bound MNP token as a rule, not an incident

§5.2, register E10 and decision 23 described the node-audience token and its
node binding partly as "before this, an operator could…". Restate them as the
design they are — the credential a member presents to a node opens nothing at
the hub and names the one node it is for — keeping the adversary named per the
document's convention but not retelling the gap.

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

1 files changed, 12 insertions, 13 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 6e3513d..baef40d 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1006,17 +1006,16 @@ a film already playing — a reconnect fetches a fresh one. `meshbay_common/toke
 holds the two audience strings, shared by the hub that issues and the node that
 verifies.
 
-**The MNP token also names the node it is for** (`node` claim = that node's
-Ed25519 key), and the node refuses one that names a different key. The client
-knows the target node's key before it connects and asks for a token bound to it.
-This closes the one thing the audience split alone did not: a member's token,
-handed to the operator of node A, could otherwise be **replayed to node B** the
-member also belongs to — not to read content (that still needs node B's group
-key in the proof, which the operator lacks) but to reach node B's **pre-proof
-window** and fetch the member's *encrypted* keypair bundle for node B. Binding
-the token to node A makes node B refuse it outright. A token that names no node
-is still accepted, because the hub only ever mints one for the authenticated
-requester, so it grants nothing across accounts.
+**The MNP token names the node it is for** (`node` claim = that node's Ed25519
+key), and a node refuses a token that names a different key. The client knows
+the target node's key before it connects (from `/v1/groups/{id}/nodes`) and asks
+for a token bound to it. So the credential a member hands one operator is of no
+use at any other node the member belongs to: not for a session there — the
+group-key proof already refuses one to whoever does not hold the key — nor for
+the **pre-proof window**, where a token accepted at face value would otherwise
+fetch the member's *encrypted* keypair bundle for that node. A token that names
+no node is accepted, since the hub mints one only for the authenticated
+requester and it therefore grants nothing across accounts.
 
 **Authorization rules:**
 
@@ -3249,7 +3248,7 @@ had already been asked.
 | **E7** | **Several named roots** per group, forming one virtual root (§6.2) |
 | **E8** | **exFAT/NTFS and Windows are the common case.** Linux ships first; that is build order, not population (§10) |
 | **E9** | **Group-related server state lives on the node. Always** (§1.3) |
-| **E10** | **The credential a member presents to a node is not the one the hub API accepts.** A member hands its handshake token to the node operator, who is in the threat model, so it is a short-lived node-audience token (`aud = MNP_AUD`, §5.2), useless at the hub API; the session token (`aud` = hub API) is never disclosed to a node. Before this the member presented its hub session token, so an operator held a live hub credential for the member — enough to enumerate their other groups and act as them at the hub. The token also **names the node it is for** (`node` claim), so a token captured by one node's operator cannot be replayed to another node the member uses — not even to reach its pre-proof window. Closed by the audience split, the node binding, and the MNP 4.0 flag day (§5.6) |
+| **E10** | **The credential a member presents to a node opens nothing else.** A member hands its handshake token to the node operator (in the threat model), so it is a short-lived node-audience token (`aud = MNP_AUD`, §5.2): the session token that opens the hub API is never disclosed to a node, and the MNP token names the one node it is for (`node` claim) so it cannot be presented to another node the member uses. Established by the MNP 4.0 flag day (§5.6) |
 | **O1** | Initial key setup in the pre-proof window — deferred; that window is where C4 and C5b came from |
 | **O2** | A LAN enrolment door — one endpoint, bounded window, one-time code, closing permanently on success |
 | **O3** | `device_policy {allow_bundle: false}`, signed by a pinned key — **the mechanism that actually closes C4** (§3.7) |
@@ -3291,7 +3290,7 @@ had already been asked.
 20. **Private keys never leave the device on native clients.** Qualified: a browser has no durable storage of its own and still needs a bundle on each node, so C4 closes for an *account* only when it opts out of browser use.
 21. **Hub minimisation is enforced by an acceptance test, not by policy.** The hub must be *unable* to see keys, content or file listings.
 22. **No new code exchanges between people.** Safety numbers are refused for identity verification, permanently. The device-linking code is between a person's own devices and is unaffected. The total user-visible cost of the whole authorship story is **one notice**: *"this account's key changed"*.
-23. **A member's credential to a node is audience-separated from its hub credential** (**E10**, §5.2). The handshake carries a short-lived `aud = MNP_AUD` token, never the hub session token; the hub API accepts only its own audience. A node operator therefore holds nothing that acts at the hub.
+23. **A member's credential to a node is separate from its hub credential and bound to that node** (**E10**, §5.2). The handshake carries a short-lived `aud = MNP_AUD` token that names the node it is for, never the hub session token; the hub API accepts only its own audience, and each node accepts only a token that names it. A node operator therefore holds nothing that acts at the hub or at another node.
 
 ### 14.2 Client architecture