Clarify the trust scope of MCP gateway policy receipts

[RobLe3]

Question, not an implementation defect

Clarify the intended trust scope of the MCP gateway's policy_receipt. This is informational review, deferred until after pre-1.0 qualification. No signing change is currently required or authorized.

The Correctover / CCS report dated 2026-09-28 tested Python iicp-client / iicp-node 0.7.109 from PyPI, not the initially preferred Rust CLI. The unmodified gateway exposed format_json,summarize_text with a local Directory stub/local MCP server and an external verifier 1.3.0. This is bounded execution-assurance composition, not complete IICP discovery/selection/dispatch-ticket interoperability or qualification credit.

Source baseline

Release v0.7.109 resolves to 7718dd35904568f3a10777a11ee3a3ffeeeaffab.

• McpToolPolicy.receipt emits structured, content-minimized policy metadata; it has no detached signature, signer, expiry or nonce.
• Gateway response places task_id beside the successful result and policy receipt. Correlation is not itself authenticated attestation of execution.
• Rust and TypeScript expose related redacted policy receipts. They are parity consumers, not three independent owners of a new shared semantic contract.
• The IICP specification owns binding/trust semantics; this repository owns the implementation used in the experiment. Generic composition is tracked in Track composable external execution-assurance evidence across IICP bindings IICP#256.

Review questions

• Is the current receipt local/transient diagnostic evidence, application-visible policy-decision evidence, externally verifiable authorization evidence, or an intermediate input to a later artifact?
• Which claims can a caller reasonably rely on today? What is outside the receipt's intended trust scope? The report's broader suggestion that both receipt models were detached-signed contradicts the tested policy receipt and must not become documentation.
• Do existing task/attempt identifiers or signed IICP artifacts already provide the needed correlation/evidence? Would a later completion/provenance artifact be a better location than changing this object?
• Should receipts remain unsigned? Only an independently justified trust requirement can lead to a separate signing proposal; external CCS signatures are not a reason by themselves.
• If signing is later justified, review signer/key authority, lifecycle/rotation, canonicalization, nonce, freshness/expiry, replay resistance, immutable correlation, privacy, verification scope and shared SDK behavior. Determine Profile versus binding-local or implementation-local scope before implementation.
• Preserve exclusion of tool arguments, prompts, credentials and responses. Avoid treating digests or a signed issuer assertion as proof of confidential execution or the truth of the assertion.

Acceptance and revisit trigger

After qualification, revisit on an accepted trust-model review or a concrete external relying-party need. Publish an as-is trust-scope decision, reuse existing architecture, and document any remaining requirement separately. A reviewed decision to keep the receipt unsigned is a valid outcome. Any future cross-SDK requirement belongs in the specification and needs separately reviewed owning-repository changes.

Do not change the current candidate, support matrix, wire contract, qualification state/credit, gateway code, vocabulary or signatures in this task. Do not add CCS packages, import ELv2 source, schedule a new experiment, or infer certification from the externally reported 14/14 case outcomes and 415/426 checker checks.

Evidence record

Sanitized dated record is available in draft documentation PR #257, pending merge and normal review/validation closure. It retains report-only results and unavailable reproduction artifacts; no qualification credit or implementation requirement is introduced.