demo · integration layer · non-normative

Gateway response binding

The MCP-gateway scenario: the tool server seals every tool response into an iqa:// envelope — the envelope's subject is sha256(response bytes)[:32], signed by the server's organ key. The gateway verifies the pair offline: no network, no directory, local clock only. Answering docker/mcp-gateway#596: the flipped-byte check, connected to response verification. Runnable Python twin: examples/gateway-response-binding.

The policy pinned out of band — data, not a lookup

The route is derived from the authority (one SHA-256 — addressing without a landlord). The signer AID is self-certifying (SHA-256 of the public key, recomputed from the in-band key at verify time). The gateway operator pins both once; after that the check is pure math.

The tool response what crosses the wire


        

Server side seals every response

ts and nonce are inside the signature — rewriting the replay window would require breaking Ed25519, not editing JSON.

Gateway side five steps, fail closed

The flipped byte, connected

Press a case: the gateway re-runs all five steps on tampered input. The point of the demo is which step catches each attack — the response-binding check fires even when the envelope's own signature is still perfect.

Reproduce it yourself the Python twin of this page

pip install "iqa-org[ed25519]"
python demo.py    # from examples/gateway-response-binding — ALL CHECKS BEHAVED AS DESIGNED

Scope note, stated plainly: the envelope names the response (a hash) and proves who signed it; it does not encrypt it, and the trust anchor for “is this the right key” is the operator's pinned policy — not a registry. Envelope rules are normative in AICENT-009 §10; the server/gateway roles on this page are placeholders.