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.