feat(protocol): bind the MNP token to the node it is for (E10)

The audience split stopped a member's node credential from opening the hub API.
It did not stop the credential being *replayed to another node*: the MNP token
carried the member's whole group set and named no node, so a token handed to
node A's operator could be presented to node B the member also belongs to. That
does not read content on B — the handshake still requires proving node B's group
key, which the operator lacks — but it reaches B's pre-proof window and fetches
the member's *encrypted* keypair bundle for B (offline-attackable, bounded,
audited): a disclosure §2.4 says should not follow from hosting a member on A.

The token now names the node it is minted for (a `node` claim = that node's
Ed25519 key), and authorize_token refuses one that names a different key. The
client already knows the target node's key (from /v1/groups/{id}/nodes) and asks
for a token bound to it: POST /v1/nodes/mnp-token takes node_pk, and
transport.connect threads it (group-page, the connection pool and rewrap pass
n.pk_node; reconnect preserves it). A token that names no node is still
accepted, because the hub only mints one for the authenticated requester, so an
unbound token grants nothing across accounts — which also keeps non-binding
callers working with no churn.

Done before deploy, so it folds into the MNP 4.0 flag day rather than needing
its own. Docs: §5.2, register E10, MESHBAY_NODE_PROTOCOL.md §6.3.
test_handshake.py and test_mnp_token.py hold the binding (a token for node A is
refused by node B, accepted by node A; an unbound token still works); red
before, green after. common/node/hub suites green.

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

1 files changed, 13 insertions, 1 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 394dfb5..6e3513d 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1006,6 +1006,18 @@ 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.
+
 **Authorization rules:**
 
 - `group_id` is **mandatory**. Omitting it once skipped the membership check and
@@ -3237,7 +3249,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. Closed by the audience split and the MNP 4.0 flag day (§5.6) |
+| **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) |
 | **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) |