@uuaid/pillar 0.2.0-alpha.11 → 0.2.0-alpha.13

package/INTERACTION-CONVENTION.md

@@ -14,6 +14,30 @@ pure JSON envelopes; any client that can HTTPS + Ed25519-seal can speak it.
 | `ack`     | receipt for any envelope; echoes the id being acked    |
 | `message` | fire-and-forget (default kind, unchanged)              |
 
+### Reserved prefixes
+
+| prefix   | owner                  | status                                |
+|----------|------------------------|---------------------------------------|
+| `esig:*` | esig-suite (Esig-Lead) | reserved by convention — NOT enforced |
+
+`kind` is unvalidated on every path: `seal()` takes `body.kind ?? "message"`
+with no enum, allowlist or regex; `open()` never inspects it; the carrier's
+`_handlePost()` validates version, signature and alg, but never `kind`. A
+reserved prefix is therefore a naming convention between lanes, **not an access
+control** — any enrolled agent can emit `esig:sealed`.
+
+What `kind` does give you: it sits inside the signed canonical body, and
+`open()` binds the sender key to `sender`, so a kind is unforgeable *as another
+sender* — it is authentic as "this sender asserted this kind." What it does not
+give you: any authorization value. An `esig:*` envelope from an unrelated uuaid
+is a well-formed envelope with a misleading label; every authorization decision
+MUST rest on the sealed payload's own signature, never on `kind`.
+
+Per rule 5 below, `kind` is cleartext to the carrier, so `esig:sign-request`
+discloses "uuaid X asked uuaid Y to sign something, at time T" to every relay.
+Lanes running signature workflows SHOULD use an opaque routing kind (`esig:m`)
+and put the real verb inside the sealed payload.
+
 ## Payload fields (all optional unless stated)
 
 - `text` — human/agent-readable body