Recognize external execution evidence (controller-signed receipts) on the verification side (cMCP #301)

[carloshvp]

Spec section

Verification (Section 3.3), Scope (2.4 and 3.4), and the cMCP reference implementation (Section 5).

Problem

cMCP issue agentrust-io/cmcp#301 (Option A, confirmed) adds an optional external_execution_evidence receipt to a cMCP audit entry: an independent authority (for example a safety controller) signs an assertion about a specific call (issuer, issuer_key_id, signature, evidence_hash, evidence_type, linked_call_id), bound by linked_call_id to the entry call_id. It is distinct from response_payload_hash (what the gateway forwarded). cmcp-verify now checks the receipt when configured with the issuer trusted key. TRACE should describe how a verifier treats such evidence so the spec and cmcp-verify stay aligned.

Proposed change

Add verification-side guidance that:

• External execution evidence is out-of-band evidence signed by a non-gateway authority, distinct from gateway-produced fields. It is only as trustworthy as the issuer key, whose trust is established out of band (a PKI / trust-anchor concern, the same shape as the manifest issuer anchor discussed for cMCP #302).
• A conforming verifier, when supplied an issuer trust anchor, verifies the issuer signature over the canonical receipt (all fields except signature) and checks linked_call_id against the bound call.
• Verifying external execution evidence is optional and does not affect the validity of the gateway-produced Trust Record. A present-but-unconfigured receipt is unverified, not invalid.
• This stays within TRACE's permanent scope boundary: TRACE binds evidence, it does not assert that a physical action occurred or that it is functional-safety certified.

No required-field change to the Trust Record. The receipt lives on the cMCP audit entry (cMCP schema), within the audit chain the Trust Record already commits, so this is verification guidance rather than a wire-format change.

Impact

• Backward compatible: yes (guidance plus optional verification; no Trust Record format change).
• Affects conformance level(s): Level 1+ optionally.
• Conformance tests that need updating: optionally add an external-evidence verification case in trace-tests; existing tests unaffected.
• Regulatory mapping impact: supports accountability for independent downstream actions (informational).

Alternatives considered

• Put the receipt into the Trust Record itself: rejected, the receipt is per-call and belongs on the cMCP audit entry; the Trust Record already commits the audit chain, so referencing it there is sufficient and keeps the Trust Record gateway-scoped.
• Treat a present-but-unverifiable receipt as a hard record failure: rejected, that would let an unconfigured verifier reject otherwise-valid records; unverified-optional is the right default.

[arian-gogani]

the nobulex receipt is exactly the shape described here — an external execution evidence record signed by a non-gateway authority, independently verifiable against the issuer key, bound to a specific call by action_ref.

concretely: action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})) is the content-derived identifier. a verifier holding the four preimage fields recomputes it and checks the Ed25519 signature over the canonical field set — no gateway trust required.

opened a PR to agentrust-io/integrations adding Nobulex as a reference implementation of this pattern: agentrust-io/integrations#6. the README there is explicit about what it does and does not claim — receipts are not Trust Records, they're the external evidence a verifier optionally checks alongside one.

happy to adjust the shape if the spec guidance lands differently from what i've described.

[vaaraio]

The external_execution_evidence slot is the right shape. One property decides whether it carries weight on the verification side: can the verifier recompute the evidence itself, or does it have to trust the issuer's say-so?

If evidence_hash is a digest over the canonical bytes of the signed assertion and the signature verifies against issuer_key_id alone, the verification side re-derives the verdict with zero trust in the producer. That is the line between recognizing a receipt and reproducing it.

I ship a producer built that way: a content-addressed execution receipt (JCS-canonical, ES256), public conformance vectors, and a standalone checker that recomputes the verdict from the receipt and the public key without importing my code. If it is useful to test the verification path against a concrete external source, the spec and vectors are at github.com/vaaraio/vaara/blob/main/SPEC.md. I can map my fields onto your linked_call_id, evidence_hash, and evidence_type so the two line up.