diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 2 | ||||
| -rw-r--r-- | docs/MESHBAY_NODE_PROTOCOL.md | 7 |
2 files changed, 6 insertions, 3 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index baf8e1e..0284dbe 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -1131,7 +1131,7 @@ token (E10).** A member hands whatever it presents here to the node operator, who is in the threat model, so the credential must open nothing at the hub. The hub signs two audiences with its one key: a session token (`aud` = the hub API) for `hubFetch` and signaling, and a short-lived **MNP token** (`aud = MNP_AUD`, -from `POST /v1/nodes/mnp-token`) that carries the member's `sub`, `jti` and **the +from `POST /v1/nodes/mnp-token`) that carries the member's `sub`, `username`, `jti` and **the one group the connection is for** — never the member's other groups, which the operator it is handed to has no business learning — and is the only thing presented in the handshake. The node binds `MNP_AUD` diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md index 0b5213c..0045f78 100644 --- a/docs/MESHBAY_NODE_PROTOCOL.md +++ b/docs/MESHBAY_NODE_PROTOCOL.md @@ -489,8 +489,11 @@ absent. `verify_proof` compares with `hmac.compare_digest`. | *(after the proof)* the roster admits `sub` for `group_id` — an active member row, or the node-wide operator row | `This node has not admitted you to this group`, code `not_authorized_for_group` | the key proves possession and the token the hub's view; the node's own answer is the roster. Someone revoked here but still a hub member, holding the key, is refused a session | `AuthorizedPeer` carries `user_id`, `group_id`, `username`, `jti` — and deliberately -**no user public key**. `username` is read from a `username` claim that neither the MNP -token nor the hub session token carries, so it is empty in practice. A key arriving in a token would be a key the hub chose, and the +**no user public key**. `username` is the MNP token's `username` claim, the account's +hub name (cut to 64 characters). It is a label, never authority: after the handshake the +node writes it into the roster for an account whose pinned name is empty — admission +by link, by device or into an open group carries no name — and an invitation's name is +never overwritten. A key arriving in a token would be a key the hub chose, and the node records the uploader's key in order to decide who may later delete a file: that would let whoever issues tokens decide it instead. Identity keys are pinned by the node's roster. The hub certifies accounts, not keys. |