From a7c891943bb231dde63aff75f56d0118e63fed68 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Mon, 22 Jun 2026 11:02:27 -0700 Subject: [PATCH] =?UTF-8?q?spec:=20add=20=C2=A73.3.1=20verification=20guid?= =?UTF-8?q?ance=20for=20external=20execution=20evidence=20(#34)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes #34. Adds a new subsection under §3.3 defining how a conforming verifier handles optional out-of-band receipts attached to audit-chain entries. Core rules: verify issuer signature and linked_call_id when the issuer key is configured, fail closed on mismatch, treat unknown-issuer receipts as unverified-not-invalid, and surface an advisory status rather than silently ignoring them. Explicit trust boundary: TRACE binds the receipt; it does not certify physical actions or safety compliance. Co-Authored-By: Claude Sonnet 4.6 --- spec/trace-v0.1.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/spec/trace-v0.1.md b/spec/trace-v0.1.md index e582143..68faee3 100644 --- a/spec/trace-v0.1.md +++ b/spec/trace-v0.1.md @@ -223,6 +223,24 @@ Any party — browser, CLI, in-cluster verifier, third-party auditor — verifie No callback to the issuer. No vendor in the trust path beyond silicon root and transparency log operators. +#### 3.3.1 External execution evidence (optional) + +Some deployments attach independent, out-of-band receipts to individual audit-chain entries — for example, a signed assertion from a safety controller confirming or rejecting an actuation request. The TRACE Trust Record commits the audit chain by hash; the receipts live inside that chain, not inside the Trust Record itself. This section defines how a verifier treats them. + +A receipt within an audit-chain entry is characterized by: an issuer identity (`issuer`), a key reference (`issuer_key_id`), a signature over the canonical receipt fields (`signature`), a content digest (`evidence_hash`), a type tag (`evidence_type`), and a binding to the corresponding tool call (`linked_call_id`). + +**Verification rule.** When a verifier is configured with a trusted public key for the named `issuer_key_id`: + +1. Compute the canonical form (RFC 8785 JCS) of the receipt fields excluding `signature`. +2. Verify the `signature` against that canonical form using the configured issuer key. +3. Assert that `linked_call_id` equals the `call_id` of the enclosing audit-chain entry. + +A verifier configured with the issuer key that fails any of these three checks MUST treat the audit entry as invalid and reject the Trust Record. + +**When the issuer key is not configured.** A receipt whose issuer key is unknown to the verifier is unverified, not invalid. The Trust Record's gateway-produced evidence (signature, audit-chain hash, policy hash, TEE measurement) is unaffected. Verifiers SHOULD surface an advisory status (e.g., `external_evidence_unverified`) rather than silently ignoring the receipt. + +**Trust boundary.** External execution evidence is only as trustworthy as the issuer key and the PKI behind it. TRACE binds the receipt into the audit chain — it does not certify that a physical action occurred, that it was executed safely, or that any functional-safety standard was met. Those claims belong to the issuer and its certification body, not to TRACE. + ### 3.4 Scope TRACE governs any confidential workload — AI agent execution, regulated data processing, sovereign compute, secure multi-party computation. AI agents are the forcing function and the first reference profile, not the limit of the standard.