fix: authenticate Runtime requests without persisted verification

Use the current Workspace signing identity for each request and remove binding key copies and verification handshake gates. Preserve explicit trust and revocation, migrate historical evidence, and align Runtime settings and connection tests. Retain request scope and durable replay protection with regression coverage.
2026-10-11 00:52:24 +09:00
parent 6a12b6cc34
commit 4099359560
42 changed files with 2786 additions and 4411 deletions
@@ -27,4 +27,19 @@ cargo run -p worker-runtime \
 ```

 The REST server is intended for a trusted Backend/proxy, not direct browser access.
+Workspace requests authenticate the actual HTTP request with the Workspace's current
+signing identity. The Runtime verifies signatures against its explicitly enrolled
+Workspace public key and binds the Runtime audience, Workspace/Worker scope,
+operation, method, path/query, body digest, expiry, and single-use token ID. A
+connection test is an ordinary signed `/v1/ping`; no prior handshake or saved
+verification evidence is required or consulted.
+
+Keep `trust-workspace add`, `replace`, and `revoke` as explicit operator actions.
+A self-reported public key cannot grant trust. Trust record IDs are administrative
+only and must not be copied into Backend registration or request claims. Replay
+protection uses Workspace plus the trusted key fingerprint, so re-enrolling the
+same key or rotating away and back cannot reset consumed requests. Reaccepting a
+key does permit fresh, unconsumed requests signed by that key until their short
+expiry; it does not create a separate sender-controlled enrollment namespace.
+
 For authenticated remote Runtime setup, see [`../../docs/development/server-runtime-auth.md`](../../docs/development/server-runtime-auth.md).