A SCITT Profile for AI-Agent Action Receipts

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 16 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

An AI agent books the flight, moves the money, or tells a machine on a factory floor to move an object. Afterwards someone asks a plain question: what actually happened, and who can prove it?¶

Today the answer usually comes from the party that ran the agent: its own logs, its own summary, its own word. This creates a first-party evidence problem when an action is disputed.¶

This document defines a receipt: one small, signed record per governed agent action, describing what was done, under which recorded principal class, with what verdict, and -- when the issuer records it -- under which policy. A bare receipt can be checked by anyone holding the issuing key; an enveloped one is checked against that key and the key that signed the envelope, which need not be the same (Section 4.2). Either way the check needs no access to the agent, the vendor, or any running service. It is deliberately narrow. A receipt proves that this record was issued by that key and has not been altered since. It does not prove that the agent was right, that its inputs were true, or that the world changed the way the record suggests.¶

Being narrow is the point. A record that promises more than it can support is worse than no record, because a relying party cannot tell where the support ends. This profile therefore states, in normative language, the things a receipt does not establish -- and, where the industry needs those things established, points at the separate documents that do it.¶

Three documents, one system. This revision is written as one part of a shipped, measured architecture, and a reader should be able to see the whole shape from here:¶

• This profile -- the record. One signed record per action, hash-chained (each record carries a fingerprint of the one before it, so a deletion between two presented records is visible -- a deletion from the end is not, which is what Section 5.1 is about), and carriable as a Signed Statement for registration in a transparency log (Section 4.3).¶
• The action digest [I-D.toraman-noa-action-digest], published 14 August 2026 -- the binding. A fixed, public way to compute one value from an approval and its exact execution attempt, so that records made by parties who share no schema can be shown to commit to the same action projection.¶
• Settlement evidence [I-D.toraman-noa-settlement-evidence], published 14 August 2026 -- the independent witness. For payments, a signed side artifact that lets a relying party check the effect against a public ledger's own record, instead of against the paying party's assurance.¶

The division of labour is the argument: the record says what the governed boundary decided or dispatched, the digest says which action a later document is about, and the witness says what an outside system observed. Each fails on its own (Section 8.1), and no one of them is asked to carry the others' weight.¶

The gap this fills is a specification gap, not only a product one. Protocol specifications for agent connectivity and orchestration, and the agent runtimes built on them, leave the accountability layer -- a standardized, tamper-evident, issuer-authenticated record of an agent's actions -- open. OWASP's MCP Top 10 lists "Lack of Audit and Telemetry" as MCP08:2025 [OWASP-MCP]. Several recent efforts emit signed PERMIT/DENY decision receipts for agent actions; what is missing is a single, SCITT-native, COSE-based profile for per-action receipts that is (a) carriable as a Signed Statement for registration in a Transparency Service -- a log a third party can check for consistency -- and (b) honest about exactly what a receipt does and does not prove.¶

This profile does not define a new signature container. It defines an application payload profile carried in a COSE_Sign1 [RFC9052], so the outer signature can be verified by conforming COSE implementations that support the fully-specified Ed25519 algorithm identifier used by this profile. Section 4.3 specifies the additional protected claims that make one an RFC 9943 Signed Statement, and states plainly which of those the reference implementation does not yet emit.¶

What this revision adds. Review on the SCITT mailing list in July 2026 found that the single phrase "real-world outcome" in -00 hides three claims that a consumer must be able to fail separately: whether a named person authorized this exact action before it ran, what a downstream machine reported afterwards, and whether the intended physical effect actually occurred. Section 8 and Section 9 pull them apart and require each to be reported as a result a verifier renders, not a caveat a reader has to remember. Section 10 draws the boundary around the value that lets records about one action be joined at all. Appendix A tells the whole story of this revision -- what was asked, what was built and measured, and what the document now guarantees -- and every change is listed there.¶

The base record noa.receipt/0.1 is not modified: no member is added, removed, or re-typed. What that guarantees is byte-level and nothing wider: every receipt, hash chain and checkpoint produced under -00 still hashes to the same value, its signatures are still signatures over the same bytes, and no linkage is invalidated. It does not follow that a -00 receipt is accepted by a -01 verifier -- acceptance is a separate question, answered in the next paragraph.¶

It does not guarantee that every -00 receipt is valid under -01, and the difference is worth enumerating rather than glossing. This revision states validity conditions -00 did not: the verdict, risk-class and governance-mode vocabularies are closed with a MUST-reject (Section 2); the object is closed against unknown members (Section 3); a timestamp must be a valid RFC 3339 date-time and not merely shape-correct (Section 3.3); id is bounded at 128 code points, seven members must be non-empty strings and a present governance.compliance.verdict must be ALLOW or DENY (Section 3.1); sig.alg must be the exact literal ed25519 (Section 4.2); and the cross-field rules of Section 3.1 refuse combinations -00 permitted. A receipt carrying an out-of-vocabulary verdict, an unknown member, an impossible instant, an empty or over-long identifier, or contradictory simulation markers would have passed a permissive -00 verifier and is malformed here. A verifier's NFC configuration moves the verdict on non-NFC strings in both directions (Section 3.3).¶

For a document adopting this profile's chain convention by reference (Section 1.2), the practical statement is therefore: the construction is unchanged; the acceptance rules are stricter.¶

2. Terminology

Definitions bind every actor. Where an entry carries a requirement it names its own actor: the entries below address the Producer (what it MUST emit), the Receipt Verifier (what it MUST reject), the Relying Party (what it MUST NOT read into a value) and the Deployment (what it selects).¶

• Action Receipt: the application-layer record defined by this document -- a signed record attesting one agent action, presented either bare (the canonical JSON payload plus its native signature) or enveloped in a COSE_Sign1 (Section 4). Both presentations are defined here. It becomes an RFC 9943 Signed Statement in the enveloped form, when that envelope also carries the protected claims of Section 4.3 -- necessary conditions, with the boundary noted there. An Action Receipt is NOT a SCITT Receipt. The two documents that define the other object use it at different widths, and the difference matters. [RFC9942], Section 3 defines a Receipt generically: a COSE Single Signer Data Object carrying one or more verifiable-data-structure proofs -- inclusion, consistency, non-inclusion -- with no Transparency Service, Signed Statement or registration event required. [RFC9943] applies that object to the SCITT case, where the proof is issued by a Transparency Service over a registered Signed Statement. This document calls the SCITT case a Transparency Receipt wherever it appears (Section 7), meaning RFC 9943's use of RFC 9942's object rather than the general class. The two are different objects with different producers: a Transparency Service issues the Transparency Receipt; the agent's governed boundary issues the Action Receipt. Where this document says "receipt" without qualification inside a SCITT context, it means the Action Receipt, and it says so.¶
• Principal class: the category of authority the issuer recorded the action as being taken on behalf of. agent.principal carries one of exactly four enumerated values -- HUMAN, SERVICE, POLICY, SANDBOX_SIM -- and nothing else. It is a class marker, not an identity: it names no person, service or key, and a verifier MUST NOT read an identity out of it. SANDBOX_SIM marks a simulated action.¶
• Lifecycle verdict: the value of governance.verdict, drawn from a closed set of exactly seven uppercase tokens. (-00 called this a terminal verdict. It is not: DEFERRED records that no decision has been made, and ALLOWED records a permission a later attempt may still consume. The name is corrected here rather than carried forward.) The tokens are: ALLOWED, BLOCKED, DEFERRED, EXECUTED, FAILED, ROLLED_BACK, SIMULATED. The comparison is exact and case-sensitive; no other value is valid, and a verifier MUST reject a receipt whose verdict is outside this set as malformed rather than treating it as an unrecognized extension. Two of the seven carry the normative weight used elsewhere in this document: ALLOWED records that the action was permitted at the governed boundary, and is the verdict from which an authorization descends -- an Evidence Verifier MUST NOT accept a receipt carrying any other verdict as the authorization for an action (Section 9); EXECUTED records that the action was dispatched or attempted there, and nothing about what happened downstream (Section 8.1). EXECUTED covers both "dispatched" and "attempted": those are different states, this field does not separate them, and neither means the action took effect. The remaining five record a refusal (BLOCKED), a decision not yet made (DEFERRED), a failure at the governed boundary (FAILED), an action the issuer records as compensated (ROLLED_BACK -- the profile can check neither the original effect nor the compensation), and a simulation (SIMULATED).¶
• Simulation markers, and the rule that keeps them honest: three members can say something about simulation -- agent.principal == SANDBOX_SIM, governance.verdict == SIMULATED, and governance.sandboxed. A producer MUST make them agree: if any one of them marks the action as simulated, governance.sandboxed MUST be true, and a verifier MUST reject a receipt in which governance.sandboxed is false while either of the other two marks a simulation. The converse is deliberately permitted -- a sandboxed run may carry an ordinary lifecycle verdict -- because a deployment may exercise the real decision path inside a sandbox. What the rule buys is exactly one thing: a receipt cannot say both at once. An issuer that consistently marks a real action as simulated, or a simulation as real, produces a receipt no verifier can contradict -- the record is the issuer's account of its own run, and this profile has no external truth source for it (Section 8). Without the rule even the internal contradiction would pass, and a reader could not tell which of two markers to believe.¶
• Risk class: the value of action.riskClass, drawn from a closed set of exactly five uppercase tokens: LOW, MEDIUM, HIGH, CRITICAL, IRREVERSIBLE. The comparison is exact and case-sensitive, and a verifier MUST reject a receipt carrying any other value as malformed rather than treating it as an unrecognized extension. The value is issuer-assigned: it records the class the issuing boundary applied to this action, not an independent assessment of danger, and a relying party MUST NOT read it as one. A Deployment that gates approval authority on risk -- for example requiring a higher approver tier for CRITICAL and IRREVERSIBLE than for HIGH -- selects that tier from this field, which is why an issuer that understates it weakens its own approval requirement rather than the verifier's checks (Section 9).¶
• Governance mode: the value of governance.mode, drawn from a closed set of exactly four lowercase tokens: off, shadow, approvals_on, on. The same exactness applies: the tokens are lowercase, the comparison is case-sensitive, and any other value MUST be rejected as malformed. The field records which governance posture the issuing boundary was operating under when the receipt was produced. This profile assigns it no authorization semantics: a verifier MUST NOT infer from any value that an approval was obtained, that a policy was enforced, or that an action was permitted -- those are governance.verdict and the artifacts of Section 9.¶
• Policy: a decision rule set with a stable content hash (policyHash) used as its published identity. A deployment will normally want it to be deterministic and side-effect-free -- that is what makes a commitment to it worth anything -- but this profile specifies no way to evaluate a policy and therefore no way for a verifier to check either property; the words are a description of intended practice, not a requirement it can test. A receipt carries that hash only when the optional commitment of Section 3.3 is present; governance.ruleId alone is a label, not a commitment.¶
• Keyring: the set of verification keys a verifier trusts for this evaluation, each addressed by a key identifier. It is supplied to the verifier out of band; this profile defines neither its encoding nor how a verifier comes to trust it, and every statement here about a "trusted key" means "a key in the keyring the verifier was given".¶
• Identity manifest: an out-of-band, operator-vouched binding of agent.id to its authorized key identifier(s) (kid), used to authenticate which agent acted, not merely that a trusted key signed.¶
• Genesis-bound chain: a per-scope hash chain whose checkpoint authority is bound to the opener of the chain -- precisely, to the keys an identity manifest authorizes for the agent.id of the receipt at sequence 0 (Section 5.2), which is a set rather than one key -- so that a re-heading attacker cannot substitute a foreign checkpoint. Without a manifest there is no such binding and the property does not hold.¶
• Transparency Service (TS): as defined by the SCITT Architecture [RFC9943].¶
• Pre-execution authorization: a statement, made before an action runs, that a named, accountable principal approved that exact action under stated bounds. It is a statement about what may happen.¶
• Post-execution evidence: a statement, made after an action was dispatched, about what some party observed. It is a statement about what did happen, under that party's own semantics.¶
• Controller-reported outcome: the terminal status a downstream system reported for a request, under that system's own semantics. It is evidence about a report, not about an effect.¶
• Physical completion: whether the intended real-world effect actually occurred, as observed by an identified witness under a criterion fixed before execution.¶
• Consumer intent (purpose): the question a relying party is asking of a presented record -- for example "is this an authorization?", "is this independent outcome proof?". Cryptographic validity is evaluated against the artifact; sufficiency is evaluated against the intent, and the two results are separate (Section 8.2).¶
• Authorization signer / outcome signer: the key that signed the authorization record, and the key that signed an outcome statement about the same action. Their relationship is a property a verifier derives, not a property either signer may assert about itself (Section 6.1).¶
• Shared action digest: a value, computed under a pinned construction, that lets records produced by different parties be joined as committing to the same action projection. Correlation only, and never a statement that the action was authorized; see Section 10.¶

3. Receipt structure (payload)

Every requirement below names its actor: construction rules bind the Producer, validation rules the Receipt Verifier, the tenant rule of Section 3.3 the Chain Verifier, and the comparison rules for identifiers and timestamps the Relying Party (Section 1.4).¶

The receipt payload is the JSON Canonicalization Scheme (JCS) [RFC8785] serialization of a JSON object. A Producer MUST emit integers only (no floating-point), and a Receipt Verifier MUST reject a payload carrying a non-integer number. String normalization is specified in Section 3.2: producers MUST emit NFC, and verifiers MUST NOT normalize. A verifier MAY be configured to refuse a non-NFC receipt, but a verifier that accepts one MUST NOT repair it, and in either mode a Relying Party MUST NOT infer that a verified receipt's strings are NFC (Section 3.3). The fields:¶

{
  "spec":   "noa.receipt/0.1",
  "id":     "<receipt id>",
  "ts":     "<RFC 3339 date-time>",
  "scope":  { "tenant": "<id>"?, "chain": "<chain id>" },
  "agent":  { "id": "<agent id>",
              "model": "<vendor/model|null>"?,
              "principal": "HUMAN|SERVICE|POLICY|SANDBOX_SIM" },
  "action": { "id": "<tool/action id>",
              "canonical": "<risk-table key>",
              "riskClass": "LOW|MEDIUM|HIGH|CRITICAL|IRREVERSIBLE",
              "paramsHash": "sha256:<hex>|hmac-sha256:<hex>",
              "reversible": <bool>,
              "rollbackRef": "<id>|null"? },
  "governance": { "mode": "<governance mode>",
                  "verdict": "<lifecycle verdict>",
                  "sandboxed": <bool>,
                  "ruleId": "<id>|null"?,
                  "approval": { "by": "<approver>",
                                "at": "<RFC 3339 date-time>" }|null?,
                  "compliance": { "policyHash": "sha256:<hex>",
                                  "readSetHash": "sha256:<hex>",
                                  "inputsHash": "sha256:<hex>",
                                  "verdict": "ALLOW|DENY"? }|null? },
  "chain":  { "seq": <int>,          ; >= 0
              "prevHash": "sha256:<hex>|null",
              "hash": "sha256:<hex>" },
  "sig":    { "alg": "ed25519",
              "kid": "<key id>",
              "value": "<base64 Ed25519 signature>" }
}

The object is closed. A receipt MUST contain no member other than those shown here, at any level; a verifier MUST reject an unknown member rather than ignore it. Extension by adding members is therefore not possible in noa.receipt/0.1 -- that is what makes the hash construction of Section 4.2 reproducible across implementations, and it is why Section 8.4 carries new claims in separate artifacts instead.¶

A ? marks a member that MAY be absent; every other member is REQUIRED, including sig. No member of this record is added, removed, or re-typed by this revision; -00's figure omitted sig and did not mark the optional members, and both omissions are corrected here to match the shipped schema (Section 3.3).¶

A Producer MUST NOT place raw prompts, tool arguments or secrets in any member, and the commitments this record carries are hashes rather than values. That is a rule about what a producer may write, not a property the format enforces, and its limit is worth stating precisely -- several members (id, agent.id, agent.model, action.id, action.canonical, governance.ruleId, governance.approval.by, action.rollbackRef) are constrained in length and emptiness at most (Section 3.1) and in content not at all, so a producer can put anything in them and no verifier can detect it. The prohibition binds producers; it is not a property a verifier can check, and Section 14 says what follows. paramsHash MAY be hmac-sha256:<hex> with a tenant-scoped key where a plain SHA-256 over a low-entropy value (an amount, an id, a boolean) would be guessable.¶

These commitments are per-producer, and this profile does not make them comparable. Neither action.paramsHash nor the three hashes of governance.compliance has a preimage construction defined here: what is hashed, in what serialization, under what domain separation, is the producer's own contract with whoever will later open the commitment. Two conforming producers given identical parameters can therefore compute different values -- by design rather than by omission. Section 10 explains why a cross-producer join key needs a construction identifier before any two parties may compare digests, and names the companion that defines one. A verifier MUST NOT compare these values across producers, and MUST NOT treat equality of them as evidence of anything. For the keyed form the same reasoning cuts harder: the key is a tenant secret, so an offline third party cannot check an hmac-sha256 commitment at all, and this profile defines no key identifier, rotation rule or distribution mechanism for it. A producer that rotates that key can still open earlier commitments for as long as it retains the retired key -- and cannot once it destroys it. Which of those happens is a deployment's key-management decision, not something this profile requires or can check; what it means is that the openability of a keyed commitment depends on a practice outside the record.¶

chain.hash is "sha256:" followed by the lowercase hex of SHA-256 over the JCS serialization of the receipt with chain.hash and sig.value removed; Section 4.2 pins that construction byte-exactly, together with the signature computed over the same digest. Receipts in one scope.chain are linked by prevHash; prevHash is null only at the genesis receipt (seq == 0).¶

4. COSE Signed Statement profile

A receipt may be presented in two forms, and this profile defines both. A receipt's payload is the JSON object of Section 3, and its native signature (Section 4.2) is computed over that object; a receipt presented as payload plus native signature, with no COSE envelope, is a bare receipt. A receipt carried inside a COSE_Sign1 is an enveloped receipt, and only an enveloped receipt can become a Signed Statement (Section 4.3). Both forms are legitimate presentations: the reference implementation's chain path verifies bare receipts and never touches COSE (Section 12), while its COSE path produces the enveloped form. Every requirement below that names the envelope applies to the enveloped form only; a Receipt Verifier given a bare receipt checks the payload, the recomputed chain.hash and the native signature, and reports that no envelope was present. Whether a SCITT-native profile should require the envelope is left open (Section 15).¶

HASH-INPUT = JCS( the receipt object with exactly two members
                  removed: chain.hash and sig.value; every other
                  member, including sig.alg and sig.kid, is present )

MESSAGE    = UTF8("NOA-Receipt-v0.1-sig:")  ; 21 octets: tag then ":"
          || SHA-256(UTF8(HASH-INPUT))      ; RAW 32-octet digest,
                                            ; NOT its hex form
                                            ; 21 + 32 = 53 octets

sig.value  = base64(Ed25519(MESSAGE))       ; standard alphabet,
                                            ; with padding
sig.alg    = "ed25519"                      ; exact lowercase literal
chain.hash = "sha256:" || lowercase-hex(SHA-256(UTF8(HASH-INPUT)))

5. Hash-chaining and completeness

This section's number, title and anchor are unchanged from -00, and the construction it defines is unchanged. Two sentences of -00's paragraph were factually wrong and are corrected here rather than reproduced and contradicted twenty lines later. Appendix A states the before and after, for the benefit of a document that adopts this section by reference (Section 1.2).¶

Each receipt carries a monotonic chain.seq (genesis = 0) and prevHash. A Chain Verifier checking a presented chain MUST verify: each prevHash equals the prior receipt's chain.hash; the genesis receipt has prevHash == null; and, when a signed checkpoint is present and an identity manifest is supplied, that the checkpoint was signed by one of the keys that manifest authorizes for the genesis receipt's agent.id, so that a foreign checkpoint produced by a re-heading attacker is rejected -- without a manifest that binding does not hold (Section 5.2). This profile detects in-band tampering within a presented chain, and detects tail truncation only against an authenticated checkpoint (Section 5.1), never from the presented set alone; it does NOT, by itself, detect equivocation (an issuer signing two divergent chains) -- that requires registration in a SCITT Transparency Service or an equivalent external witness.¶

{
  "spec":       "noa.checkpoint/0.1",
  "chain":      "<chain id>",         ; the scope.chain it speaks for
  "highestSeq": <int>,                ; chain.seq of the head receipt
  "headHash":   "sha256:<hex>",       ; chain.hash of that receipt
  "ts":         "<RFC 3339 date-time>",
  "sig":        { "alg": "ed25519", "kid": "<key id>",
                  "value": "<base64>" }
}

CHECKPOINT-HASH-INPUT =
    JCS( the checkpoint object with exactly one member removed:
         sig.value; sig.alg and sig.kid remain present, and there
         is no chain.hash member to omit )

CHECKPOINT-MESSAGE =
       UTF8("NOA-Checkpoint-v0.1-sig:")   ; 24 octets: tag then ":"
    || SHA-256(UTF8(CHECKPOINT-HASH-INPUT))
                                          ; RAW 32-octet digest,
                                          ; NOT its hex form

sig.value = base64(Ed25519(CHECKPOINT-MESSAGE))
sig.alg   = "ed25519"

6. Identity binding

Attribution addresses the Receipt Verifier, conditional on an identity manifest being supplied. The relationship rules of Section 6.1 address the Evidence Verifier and depend on artifacts listed in Section 1.5.¶

agent.id is a signer-asserted label. To authenticate WHICH agent acted (not merely that a trusted key signed), a verifier MAY be supplied an identity manifest binding agent.id to its authorized key identifiers.¶

Each signature attributes a different party, and the manifest answers only one of the two questions. An enveloped receipt carries two identifiers, and treating either as a substitute for the other is the failure this subsection exists to prevent:¶

• The native sig.kid attributes the agent: it is the key that signed this receipt into its chain, and it is the identifier agent.id makes a claim about. When a manifest is supplied, a verifier MUST check the (agent.id, native sig.kid) pairing against it, and MUST reject an unauthorized pairing as UNTRUSTED -- a result distinct from both "valid" and "tampered": the bytes are intact and the signature verifies, and the key that produced it is not one this agent.id is authorized to use. A verifier MUST report that as its own outcome rather than folding it into a signature failure, for the same reason Section 5.1 separates its conditions.¶
• The outer COSE kid attributes the party that emitted this envelope -- an issuer submitting its own receipt, or a relay presenting someone else's. A verifier that reports it as an identity at all MUST take it from the protected bucket, since an unprotected identifier is not covered by any signature. This profile defines no authorization list for that party: the manifest binds agents to keys, not envelopes to emitters.¶
• Therefore two rules, and they are the ones that close the laundering. A verifier MUST NOT use an authorized outer kid to satisfy the agent check: an envelope signed by a key that happens to be authorized for agent.id says nothing about who signed the receipt inside it. And a verifier MUST NOT reject a receipt solely because its outer signer is not one of the agent's authorized keys: a relay is a legitimate presentation, and the agent claim is carried by the native signature it did not touch. A verifier MUST report the two results separately.¶

A checkpoint has one signature and one claim: the manifest check is against the checkpoint's own sig.kid, under the opener-binding rule of Section 5.2.¶

Without a manifest, attribution is key-level only -- "some key the verifier trusts signed this" and nothing about which agent -- and a verifier MUST surface that limitation to the relying party.¶

7. Registration in a Transparency Service

This section addresses the Transparency Service, except the first sentence, which addresses the submitting Deployment.¶

A receipt carrying the protected claims of Section 4.3 is a Signed Statement and MAY be submitted to a Transparency Service. A receipt without them is not, and MUST NOT be described as registrable.¶

The Registration Policy for this profile is stated as a list because each item closes a specific substitution. A Transparency Service registering a statement under this profile:¶

1. MUST verify the outer COSE_Sign1 signature, and MUST verify it with a key it has bound to the Issuer named in iss -- the resolved key or certificate belongs to that Issuer, or an explicit delegation from that Issuer to the signing key is presented and checked. [RFC9943], Section 6.3 states the same requirement in its own terms: the signature is verified with the verification key of the Issuer. A service that cannot make that binding MUST NOT record the statement as that Issuer's;¶
2. MUST verify the protected header conforms to Section 4.1 -- an alg of -19 and deterministic CBOR -- and MUST require a protected kid for registration specifically. A receipt whose kid is only in the unprotected header conforms to Section 4.1 and is not registrable under this policy: registration binds a subject to an issuer, and an identifier the signature does not cover cannot do that. Producers intending to register MUST protect the kid;¶
3. MUST verify that protected CWT_Claims are present and carry both iss and sub;¶
4. MUST verify that the payload is a well-formed receipt under Section 3; and, where it can resolve the native signer's key, MUST verify the payload's native signature. Registering an envelope whose payload is a forged receipt is precisely the attack the outer signature does not stop, since Section 4.2 permits the two signers to differ. This profile defines no way for a Transparency Service to obtain that key -- the keyring is an out-of-band input (Section 2) -- so where the service cannot resolve it, it MUST refuse the registration. The alternative a reader might expect, registering while attesting that the payload was not checked, is not available: this profile defines no header, claim, log-entry field or media type in which that status could travel, so a later reader could not distinguish it from a checked one. Refusal is the only outcome this document can specify without inventing a carrier it has not defined. A future revision that defines one MAY relax this;¶
5. MUST verify that sub equals the payload's scope.chain, so that the subject a log indexes is the chain the statement is actually about; and¶
6. The issuer/submitter relationship is the sixth item, and it is guidance rather than a requirement, because this document cannot make it testable: a Transparency Service applies its own policy to the relationship between the Issuer named in iss and the party submitting the statement, and records which policy it applied. This profile does not require those two to be the same party, does not define the policy, and -- decisively -- defines neither the minimum contents of such a record nor anywhere it is carried, so a service that refused every submission under an unnamed policy would satisfy any wording used here. What the profile can do is say plainly that the question exists and that a service which never asks it is registering statements whose issuer relationship nobody checked.¶

What iss is worth, and where it stops. This profile defines no issuer key discovery: no registry, no well-known location, no delegation format. Item 1 therefore states a requirement whose mechanism lives outside this document, and a deployment must supply one. Until it does -- and for any holder who has only the receipt, with no registration behind it -- iss is an issuer-asserted string: it names the authority the signer claims to speak for, and nothing in the envelope proves the relationship. A Transparency Service, and any Receipt Verifier that reads iss at all, MUST NOT report it as an authenticated identity on the strength of a valid outer signature alone, and MUST say which it had: an identity bound to the verification key, or a string the signer asserted.¶

A Transparency Service knows this policy applies by agreement with the registrant, not by inspection: no media type is registered for the payload (Section 16), so a service cannot dispatch on content type alone. Until one exists, a deployment states the profile out of band.¶

Items 4 and 5 are the ones a reader should not skim. Item 4 is what stops a trusted registrant obtaining a log entry -- and a Transparency Receipt -- for a receipt nobody in the chain ever signed. Its cost is stated rather than hidden: a Transparency Service that cannot resolve native signer keys registers nothing under this profile, which is a real operational constraint and the honest consequence of having no way to publish "not checked". Without item 5 an issuer can register a chain-A receipt under sub = chain-B, leaving the log holding a subject history that no receipt supports. On success the TS returns a Transparency Receipt: a third party's signed proof that this statement was registered in its log. In [RFC9942]'s terms that is a proof about the log's verifiable data structure, not the COSE countersignature header parameter of [RFC9052]; the two are different constructs, and this profile means the first everywhere it says Transparency Receipt.¶

What registration is worth, stated exactly. An inclusion proof establishes membership in the view that log served. Non-equivocation -- that the log did not serve one history to one party and a different history to another -- is not established by any single receipt. It requires consistency proofs between log states and a party that monitors them; this profile specifies neither the monitoring role nor any requirement on anyone to perform it, and a relying party that wants non-equivocation MUST obtain it from the Transparency Service's own ecosystem.¶

The offline case gets the same scepticism this document applies to checkpoints. A Transparency Receipt handed to an offline relying party by the prover is prover-supplied evidence, exactly like the checkpoint of Section 5.2: a better signer, and still no way for a party that never queries the log to detect a log that served two views.¶

Two further honesty notes. Nothing in Section 5 supplies any of this, so a deployment that never registers has strictly less. And no reproducible demonstration of registration against an external Transparency Service has been published for this profile (Section 12): the policy above is a specification, not a report of an executed interop.¶

8. What a receipt does not claim about the external world

The non-claims in this section constrain what any actor may assert, and each is written against the actor it binds. Two blocks are marked NON-NORMATIVE where they appear -- the claim-separation duty of Section 8.1 and the intent machinery of Section 8.2 -- because their inputs are artifacts Section 1.5 lists as undefined; the absence vocabulary of Section 8.3 is normative, because a verifier's own results are something this document can constrain.¶

A receipt in this profile is emitted at the governed boundary: the point where an action was admitted, refused, deferred, or dispatched. Everything beyond that boundary -- what a downstream controller did with the request, and what happened physically -- is outside the record.¶

9. Pre-execution authorization and post-execution evidence

This section is addressed to the Evidence Verifier (Section 1.4), over artifacts this profile does not define (Section 1.5), and is NON-NORMATIVE in its entirety: no bullet below carries an RFC 2119 requirement, none of them can be failed, and there is no exception. The requirements they point at live where they are testable -- Section 8.1 states the non-claims a receipt cannot escape, and Section 8 states what a bare receipt cannot establish. A Receipt or Chain Verifier neither satisfies nor fails anything in this section.¶

Authorization and evidence differ in time, in signer, and in failure mode. An authorization is made before the action, by a party accountable for allowing it, and fails if that party did not approve this exact action. Evidence is made after the action, by a party that observed something, and fails if the observation is not bound to the same action or its signer is not trusted for the purpose.¶

The substitution these differences permit is the one this section is about. All three bullets run over artifacts, comparisons or results this document does not define -- the hold, decision and execution-grant records of Section 1.5, and the query that would ask about a named human -- and no binding defined here establishes which grant authorized a particular attempt, or that it preceded the attempt: ts cannot supply the ordering, because it is signer-chosen (Section 3.3). They are written as what a companion defining those artifacts has to require.¶

• A verifier presented with a post-execution record where a pre-execution authorization was required has to refuse and name the failing check. The refusal is not avoided because the record's signature verifies: attribution records who was recorded as acting; it never grants authority.¶
• A machine policy decision is not a human authorization. A receipt carrying governance.verdict == ALLOWED under an automatic rule records that a policy allowed the action. Where a consumer asks whether a named human authorized it, that receipt has to yield a result distinct from an accept -- and the reason this is not a requirement here is worth naming: "a named human authorized it" is not one of the intents this document defines, the identity is supplied by nothing defined here, no comparison against the receipt is specified, and no token or result schema carries the answer (Section 1.5). The requirement that does exist is the non-claim, and it lives where its input is a receipt: Section 8.1 forbids presenting a receipt as evidence that a named human authorized the action. Per Section 8.3, an unproven result is also not a finding that no human approved.¶
• An authorization is bound to one execution attempt or it is not an authorization for the attempt that happened. Where a deployment issues single-use, time-bounded execution grants, a verifier has to check that the grant presented is the grant that authorized this attempt, and refuse a valid grant for a different attempt rather than accept it as generic permission. What makes that checkable -- a grant identifier, a single-use nonce, an audience and an expiry, and a binding to the attempt -- is exactly what this profile does not define.¶

A relying party that needs the authorization claim needs artifacts this profile does not define: a signed hold or deferral, a signed decision by a party holding an approval role, and a single-use execution grant, each under its own signing domain. Section 12 reports what the reference implementation does today, so that the gap between this profile and that implementation is a measurement rather than an impression.¶

10. The shared action digest boundary

The first rule below binds the Producer that emits a digest -- it must travel with a construction identifier -- and every actor that compares one, in practice an Evidence Verifier. The second rule binds whoever reads the comparison.¶

Records about one action are only comparable if they carry a value that means the same thing to both producers. Two rules make that possible, and this profile states both while defining neither construction.¶

Determinability, not assumption. This rule -- the one paragraph below, and nothing else in this section -- is NON-NORMATIVE here: the digest it governs is not a member of this record and is defined by a companion (Section 1.5), and it is written because a companion defining one has to carry it. The two requirements at the end of this section are normative and are labelled there. Any digest offered as a cross-producer join key travels with a construction identifier, and that identifier commits to the construction's canonicalization parameters -- serialization, member sort, number rendering, normalization, escaping, digest algorithm, and domain separation. A verifier presented with a digest under an unrecognised or non-matching construction identifier does not compare the values at all. The comparison then yields nothing -- not a match, and not a mismatch -- and is reported as indeterminate: "these records were not shown to be about the same action", never "these records are about different actions". That is the same distinction Section 8.3 draws; a question the verifier could not reach is not a negative answer to it. Two constructions that differ only in whether they apply Unicode normalization will agree on almost every input and disagree on the ones that matter; a shared vector, not a shared name, is what establishes that two parties compute the same value.¶

Correlation is not attestation. Digest equality establishes that two records commit to the same action projection -- the same field values under the same construction. It establishes nothing about whether that action was authorized, whether a controller reported anything, or whether any effect occurred; each of those fails independently (Section 8.1). A digest is a join key, and a join key that is mistaken for an authorization claim is the substitution Section 9 forbids.¶

Two rules do stay normative here, because their subject is this record. action.paramsHash does not satisfy the first rule above and MUST NOT be used as a join key (Section 3.2); and a verifier MUST NOT treat equality of any digest as evidence that an action was authorized, which is the substitution Section 9 is about. Nor does the base record carry a member for a shared digest: noa.receipt/0.1 is closed (Section 3), so a correlation value travels beside a receipt in whatever artifact references it, never inside one. A deployment that wants correlation does not modify the receipt.¶

A construction meeting both rules is published: [I-D.toraman-noa-action-digest] fixes the projection members, the domain tag, the preimage, the digest, and a published conformance corpus (counted in Section 12). One consumer of it is [I-D.toraman-noa-settlement-evidence]. This profile does not restate that construction, does not require it, and would apply the same two rules to any other.¶

On indeterminate positive controls. In an independent reconciliation run reported on the SCITT list on 27 July 2026 (https://mailarchive.ietf.org/arch/msg/scitt/zWZBQXXSGV-vgbTeOLTjlb9DGLg/), a positive control was held INDETERMINATE because the digest it carried came from a construction the reconciler had no vector for. That is the rule above working, not a harness defect: a positive control that upgrades itself on an unverified binding makes every negative case unreliable too.¶

Three things follow, and they are different things.¶

• What is now pinned. The correlation construction this profile's producers use is published byte-exactly, with its vectors, so a reconciler holding those values has something to compute against rather than assume (Section 12).¶
• What that does not do. The control that came back INDETERMINATE carries another party's digest under that party's construction. Publishing ours does not upgrade it, and this profile does not claim otherwise: that row upgrades when its own preimage rule and vectors are published. The rule is symmetric.¶
• What is still open on our side, for a digest we did not define. A party computing the reconciliation layer's own subject digest over a receipt's action object cannot do so reproducibly today, because this profile has never fixed that object's encoding: rollbackRef is optional, and present-as-null and omitted produce different digests. Every receipt in the shipped corpus carries it, which is a convention, not a rule an implementer can cite. Any party wanting to compute a digest over action therefore needs two things this revision does not provide: a normative rule fixing the encoding, and an expected value published per conformance vector so a positive control has something to equal. Both are named here as work rather than left for a harness to discover -- which is the same rule this section applies to everyone else.¶

11. Policy replay is out of scope

This section addresses the Producer and every verifier: none of them may present a receipt as carrying a re-derivable verdict.¶

A deterministic, offline policy-replay capability -- a verifier re-running the in-force policy over the recorded inputs to re-derive the recorded verdict, with no access to the agent, model, or any service -- is a distinct capability that this revision deliberately does NOT specify. The optional commitment of Section 3.3 carries hashes of a policy, its read-set, and the recorded inputs; it does not carry the replay construction (the deterministic evaluation grammar, operator set, evaluation order, and conformance vectors), which is left to a separate companion profile and is not normative here. A Producer and every verifier MUST NOT represent a receipt under this profile as carrying a re-derivable verdict, and MUST NOT infer from a present commitment that the referenced policy was adequate or in force.¶

12. Implementation status

This section is to be removed by the RFC Editor before publication, per [RFC7942]. Removing it will renumber what follows, so a citation of this revision by section number should be read against this revision. References to this section from the body are pointers to measurement, never to normative content: no requirement depends on it.¶

A zero-runtime-dependency reference implementation (signer, offline verifier, deterministic CBOR, COSE_Sign1 profile, JCS canonicalizer, conformance vectors, and separately implemented verifiers in four further languages) is available under the Apache-2.0 license at https://github.com/NordenSoft/noa. Unless explicitly stated otherwise, the measurements below are from main commit 4764cab. Later repository changes are identified by their own commit hashes and are not included in the pinned snapshot's counts. No number in this section is an estimate: each was produced by running a command or counting files in that tree. Three classes of measurement are reproducible from what is written here -- the corpus counts (three are file counts in the named directories; the action-digest and settlement-evidence corpora are each a single vectors.json whose entry array is counted, which is why counting files there gives the wrong answer), the conformance run (node impl-py/conformance.mjs), and the repository facts cited to a path. The rest -- the 25-verdict cross-field measurement below, the divergence runs of D1, and the decoded header bytes -- were produced by ad-hoc scripts that are not committed, so they are reported as measurements with their inputs described rather than as anything a reader can re-run today. Committing them is open work.¶

Algorithm identifier. The implementation emits the fully-specified Ed25519 identifier -19 ([RFC9864]) and rejects every other alg, including the polymorphic EdDSA identifier -8, which [RFC9864], Section 4.2.2 marks Deprecated (it was registered in [RFC9053]). There is one emission site and one verification gate; no code path emits -8 and no legacy-compatibility flag exists.¶

The protected header it builds is the deterministic CBOR map {1: -19, 4: kid} -- two members, because the kid is in the signed bucket, so attribution cannot be swapped without breaking the signature. Its bytes therefore begin a2 01 32 04 ..., the trailing part being the kid byte string; a measured envelope's header reads a2 01 32 04 49 ... for a nine-octet kid. A forged envelope carrying -8 under a genuine Ed25519 signature -- the only construction that tests the alg pin rather than the signature -- is rejected at the product API with "protected header alg is not Ed25519 (-19, RFC 9864)"; so are -7, alg as a text string, a non-canonical two-byte encoding of -19, a duplicated alg label, and an absent alg.¶

One implementation, stated as such. The -19/-8 behaviour above is a property of a single COSE implementation. The separately implemented Python verifier does not implement COSE at all, and the Go, Rust and C# verifiers contain none, so they provide no confirmation in either direction. A third-party check does exist and did run -- a foreign stack (cbor2 + PyCA cryptography) reads alg = -19 from a shipped vector, verifies the Ed25519 signature over the RFC 9052 Sig_structure, and rejects a tampered payload -- but that corpus holds one vector and it is a positive one. At the pinned snapshot that vector's own metadata still carried the stale a10132 header string beside an envelope whose protected header holds both alg and kid, so the file contradicted itself; df777a6 corrected it. There is no cross-implementation NEGATIVE vector for -8; that refusal is proven only inside this implementation's own tests, and closing it is one of the open vector commitments recorded below.¶

The two signatures. receiptToCose wraps the JCS-canonical receipt as the COSE_Sign1 payload; receiptFromCose verifies the COSE signature, re-canonicalizes the payload and requires byte equality with the signed bytes, and validates the receipt shape -- it does not verify the native sig.value or any chain property, which is the separate verifyChain path. The two checks are genuinely independent, which is what Section 4.2 says they are; what no entry point does is run both, recorded as a gap below.¶

Chain-level axes. All six chain conditions of Section 5.1 are detected and reported distinctly, under the implementation's own reason strings rather than under this document's labels: a broken link, a duplicate sequence number, a sequence gap, more than one chain partition in one input, the cross-tenant split, and a mid-chain key change for one agent -- the last reported as a "key swap", in both the TypeScript and the separately implemented Python verifier. What it gets wrong is the checkpoint axis, on both of its named outcomes: checkpoint-unverified is not distinguished at all, and checkpoint-head-conflict is reported over-broadly by treating a legitimate extension as one. Both are in the gap list below. scope.tenant drift across one chain is fail-closed by default, and absence of the member does not reset the comparison.¶

On the word "separately". What is demonstrated is five implementations in five languages that agree on a shared corpus, not five independent derivations of this specification: the Go, Rust and C# sources describe themselves as ports of the Python reference, and the Python one was written against the TypeScript one. Agreement between a source and its port is weaker evidence than agreement between two independent readings of a specification, and this document does not claim the stronger thing.¶

Cross-implementation conformance, run rather than cited. node impl-py/conformance.mjs, executed at the pinned 4764cab snapshot on 2026-08-14, ran 99 checks and exited 0, with its own summary line reporting that the separately implemented Python verifier agrees with the TypeScript reference on every vector, including the impersonation, truncation and duplicate-key security verdicts. The Go, Rust and C# verifiers are each compared against the Python one over a shared file-based corpus, and the TypeScript reference is compared against it too, so the topology is a star with the Python reference at its centre rather than five implementations tested against one another; what that can and cannot settle is stated at the end of the register below. No claim of demonstrated external interoperability across all five is made here.¶

Conformance gaps against this revision's own rules, at the pinned snapshot. What follows is the output of two independent reverse audits -- code read first, then the requirement it should have mapped to -- and it is deliberately long. An earlier draft of this section listed six gaps and called that the whole count; the claim was false, and the correction is to publish the register rather than to shorten it. "All five" below means the TypeScript reference and the separately implemented Python, Go, Rust and C# verifiers. A fix for the first three is in flight in the reference repository; this register describes the code as measured at the pinned snapshot, not the code as it will be.¶

One measurement covers the first three rows, and it was run rather than reasoned. Five receipts were built, each carrying action.riskClass: CRITICAL on a wire.transfer action, and each was presented as identical bytes to all five verifiers: (A) agent.principal: SANDBOX_SIM with governance.sandboxed: false and governance.verdict: EXECUTED; (B) governance.verdict: SIMULATED with governance.sandboxed: false; (C) action.reversible: false with action.rollbackRef: "snap_1"; (D) governance.verdict: ROLLED_BACK with action.reversible: false; (E) ts: "2026-13-45T99:99:99.000Z". All 25 combinations returned VALID.¶

A and B are the worst of the five, for the reason this profile exists at all: a reader has to be able to tell a real action from a rehearsal. A and B are signed, chain-valid, fully verifying receipts for an action the issuer itself classified CRITICAL, and they can be argued in both directions afterwards -- the issuer can say the record shows a simulation, the counterparty can say it shows an execution, and the receipt supports both readings. The receipt carries no amount and this profile defines no way to open paramsHash (Section 3), so nothing here establishes what the action was worth; the risk class the issuer assigned is the whole of what the record says about its seriousness.¶

• G1 -- contradictory simulation markers are accepted. Section 3.1 requires governance.sandboxed: true whenever agent.principal is SANDBOX_SIM or governance.verdict is SIMULATED. The requirement is satisfied by no shipped verifier: each validates the primitive type of the three members and stops, so cases A and B verify in all five.¶
• G2 -- contradictory rollback markers are accepted. Section 3.1 requires action.rollbackRef to be absent or null unless action.reversible is true, and a ROLLED_BACK verdict to be accompanied by action.reversible: true. Neither relationship is checked by any shipped verifier; cases C and D verify in all five.¶
• G3 -- a timestamp's shape is checked, its meaning is not. Section 3.3 requires a verifier to reject a value that is not a valid RFC 3339 date-time. Every implementation validates the shape of the string and none of them asks whether it denotes an instant, measured rather than inferred: case E -- month 13, day 45, hour 99 -- verifies in all five. The reference's own source records why it stays there, and the reason is narrower than an earlier draft of this register claimed: tightening the predicate changes no bytes, no digest and no signing domain, so it is not a wire-format change. What it changes is the set of already-signed receipts an existing verifier accepts, which the pinned source calls "an API change, never a format change" -- five implementations have to move together or they disagree on receipts nobody can re-sign. That is a release-coordination problem, not a version-of-the-record problem.¶
• G4 -- no entry point is a conforming Receipt Verifier. Section 4.2 requires a Receipt Verifier given an enveloped receipt to run both signature checks and to report which produced its result. receiptFromCose verifies the outer COSE signature, re-canonicalizes the payload and validates its shape but never touches sig.value; the native signature is checked in the chain path. A caller can obtain both properties by calling both, and nothing prevents it; what the repository does not contain at the pinned snapshot is a caller that does. The Receipt Verifier this profile defines is not an entry point the library exposes, and not one its own callers assemble.¶
• G5 -- whole-payload canonicality is proven on one path only. Section 4.2 requires JCS(parse(bytes)) == bytes over the bytes as received. receiptFromCose performs exactly that comparison; the bare chain path in all five is handed parsed values and cannot prove the original bytes were canonical.¶
• G6 -- an unauthenticated checkpoint produces an accusation. Section 5.1 requires checkpoint-unverified and forbids a truncation or tampering finding. With a keyring, all five answer TAMPERED; the four that carry a reason string give "checkpoint not authenticated against keyring" or their own wording of it, and the Go verifier returns the status token alone. Without a keyring the head comparison runs anyway: an honest, complete chain presented together with an attacker-signed checkpoint returns TAMPERED in all five -- measured, on identical bytes -- under the reference's message "tail truncated/extended". Neither branch produces the indeterminate result this revision requires, and both are the violation of Section 8.3 in its clearest form: a file anyone can hand the verifier becomes a finding against someone else's records. It is also the shape Section 5.1 now forbids in as many words: the obligation keys on whether the checkpoint authenticated, and every shipped verifier branches on whether a keyring was passed.¶
• G7 -- a legitimate extension is reported as a head failure. Section 5.1 requires a verifier to distinguish a chain that has grown past an older checkpoint from one that conflicts with it. All five compare the checkpoint tuple against the current head only and report a single verdict for both cases. In the reference the message says so in as many words -- "tail truncated/extended", which also names a cause Section 5.1 no longer permits the comparison to name; the Go verifier returns the status alone, so there the two cases are indistinguishable even in principle.¶
• G8 -- no Signed Statement mode exists, on either side, and that is a capability absence rather than a rule broken. The producer emits {1: -19, 4: kid} and no CWT_Claims, so what it mints is not registrable (Section 4.3); the verifier ignores label 15 as a non-critical header, and a committed test shows it accepting a protected header carrying a malformed 15: bstr as a perfectly good generic COSE_Sign1. No code path anywhere evaluates a receipt as a Signed Statement. This profile requires no Producer to implement Signed Statement production -- bare receipts are a defined presentation (Section 4) -- so the honest statement is that the reference cannot be registered, not that it violates a requirement. It is listed here because a reader who assumes registrability would be wrong, and because item 1 of the list further below says the same thing about the verifier half.¶
• G9 -- only the first condition that holds is reported. Section 5.1 requires a verifier to report every condition that holds. All five return on the first failure they find, so a set that is both spliced and truncated reports one of the two, and the operator's next step depends on the set rather than on whichever check ran first.¶
• G10 -- one implementation cannot distinguish the axes at all. Section 5.1 requires the six chain conditions and the checkpoint axis to be distinguishable in a verifier's output, under whatever strings it chooses. Four of the five return a status together with a reason string and distinguish the six chain conditions through it. The Go verifier returns a status token alone -- its chain entry point's return type is a single string -- so every distinction it makes internally is a source comment, and nothing beyond MALFORMED, TAMPERED and UNTRUSTED is recoverable from its output. In all five, the remaining two conditions are conflated by G6 and G7, so six is also the ceiling.¶
• G11 -- an ambiguous kid cannot be handled at all. Section 4.1 requires a verifier to try every key a kid resolves to, to accept only if exactly one verifies, and to report the identifier as ambiguous when more than one was tried. Every shipped keyring is a map from a kid string to one key, so the requirement is not expressible without changing that type: no implementation can satisfy it today and none reports the case.¶
• G12 -- a public option turns off a MUST. Section 3.3 requires a Chain Verifier to reject a transition between two present, unequal scope.tenant values. The shipped verifier exposes requireTenantConsistency, which defaults to refusing such a chain but can be set to false -- and with it set, the repository's own vector for that case returns VALID on a chain whose tenant drifts. It is documented and opt-in, which makes it a migration path rather than an accident, and it is still a configuration in which the implementation does not conform.¶
• G13 -- the two identifiers are returned, and nothing says which claim each carries. Section 4.2 requires a verifier to report the identifiers it treats as identities and to say which claim each belongs to. Both values are in fact reachable from the shipped COSE result: it returns the outer kid alongside the parsed receipt, whose sig.kid is the native one, so a caller does not have to re-read its input. What is missing is the labelling and the second check -- the result does not distinguish "this key emitted the envelope" from "this key signed the receipt into its chain", and the native signature is not verified on that path at all. G21 is the sharper form of the same defect.¶
• G14 -- the attribution limitation is surfaced by one implementation of five. Section 6 requires a verifier without an identity manifest to surface that attribution is key-level only. The TypeScript reference emits exactly that warning; the other four emit nothing.¶
• G15 -- an unanswered tail question is reported by one implementation of five. Section 5.2 requires a verifier given no checkpoint to report the tail question as unanswered rather than to omit it. Only the TypeScript result carries a tailChecked field; the other four return ordinary chain validity with no distinct absence result.¶
• G16 -- the opener-scoped qualification is missing in two implementations. Section 5.2 requires a multi-agent checkpoint result to state whose view the check covers. TypeScript, Python and C# emit that warning; Go and Rust carry no warnings channel at all, measured as zero occurrences of any warning field in either source tree -- which also makes G14 and G15 unsatisfiable there without an API change.¶
• G17 -- the approval reporting level does not exist, and the obligation that would need it is not triggered. Section 6.1 binds a verifier that reports something about an approval: it has to say whether what it holds is an opaque name on a bare receipt or complete cryptographic evidence. The shipped chain result carries a status, a chain identifier, a count, two booleans, a reason and warnings -- it does not carry governance.approval at all, so it reports nothing about approval and the conditional never fires. Nothing here is broken. What is true, and why the row stays: a consumer that wants the distinction cannot obtain it from these results, and an implementation that later begins reporting approval takes on the obligation at that moment.¶
• G18 -- the Transparency Service role is not implemented, which is coverage absence, not nonconformance. Section 7 requires a Transparency Service to check the outer signature, the protected kid, the CWT claims, a well-formed payload, the native signature where the key is resolvable, and sub == scope.chain. No implementation performs them, because none claims that role -- and Section 1.4 is explicit that an implementation conforms to the role whose obligations it performs, so declining a role is not a failure of it. The register carries the row so that a reader counting shipped coverage against this document's roles sees the hole, not because something is broken.¶
• G19 -- an unknown non-critical header can be fatal. Section 4.1 requires a verifier to ignore a header it does not understand that crit does not list. The reference's CBOR decoder refuses the whole envelope when such a header's value uses a CBOR major type it does not implement, which is a refusal reached before header policy runs.¶
• G20 -- the pinned equation is satisfied where it could be measured, and one implementation's is a property of its linked library rather than of its own source. Section 4.2 pins the cofactorless check [S]B = R + [k]A'. Read from source: the Python verifier computes exactly that equation; the Rust verifier calls verify_strict, which its own header names as cofactorless; and the Go verifier calls the standard library, whose implementation carries the comment [S]B = R + [k]A and byte-compares the recomputed point against the signature's first half. The TypeScript reference verifies through node:crypto, so the equation it executes is the one its linked OpenSSL implements, not one this repository chooses: measured on Node v23.7.0 linked to OpenSSL 3.6.3, that library's Ed25519 verifier recomputes the strict equation and names it as such, so the reference satisfies the pin in that pairing. It is stated per version because that is what was measured; a different Node/OpenSSL pairing is a different measurement, and an in-repository comment describing the path as "cofactored" is a comment about key validation and is wrong about the equation. The C# verifier delegates to a BouncyCastle assembly whose source is not present in the environment these measurements were taken in, so its equation is [UNVERIFIED] -- recorded that way rather than assumed in either direction. An earlier draft of this register asserted categorically that the TypeScript reference failed the pin, on the strength of that source comment. That was false, and the correction is recorded here rather than quietly dropped: a register that over-accuses is as unreliable as one that under-reports.¶
• G21 -- the COSE path checks the manifest against the wrong signature. Section 6 now requires the agent claim to be checked against the native sig.kid, and forbids an authorized outer kid from standing in for it. The shipped COSE path does the opposite: it pairs receipt.agent.id with the outer envelope kid and never checks the native sig.kid against the manifest at all (src/cose/receipt-cose.ts, the identity-binding block). Two consequences follow, and both were run against the built package rather than reasoned about. Legitimate relay -- native signature by the key the manifest authorizes for alice, envelope signed by an unrelated relay: ok:false, "agent \"alice\" is not authorized for signing key \"k-relay\"", refusing a presentation Section 6 says MUST NOT be refused on that ground. Laundering -- native signature by a key authorized for nobody, claiming alice, wrapped by the key the manifest does authorize for alice: ok:true, with the returned payload's native sig.kid naming the unauthorized key. Both verdicts are the reverse of the rule. The chain path is not affected -- it checks the native sig.kid -- so this is a defect of the envelope entry point only. The probe is an ad-hoc script and is not committed, which is the reproducibility class stated at the top of this section.¶

Behaviour the reference enforces that this revision does not require. These are not gaps against a rule; they are places where a receipt this profile calls conformant is refused by the reference implementation. That is an interop hazard in the opposite direction and it is stated here rather than discovered in a bake-off. The classes that earlier reviews found in this position have left this list, because this revision states them as requirements: checkpoint structure and scope; the native sig.alg literal; the key type, encoding and public-point rules; the id bound; the non-empty-string members; the forbidden member names; compliance.verdict; and the UTF-8 round trip before a kid is resolved. What remains:¶

• S1 -- a signing-key lifecycle. Section 5.2 says this revision defines no rotation or revocation mechanism. The reference has one: its keyring may be a noa.signing-key-lifecycle/0.1 document in which each key carries a retiredAt, and a receipt, checkpoint or envelope signed by a retired key is refused -- deliberately, since a signer-chosen timestamp cannot prove an artifact predates a compromise. Whether that is a divergence from the profile depends on something this document does not fix: a keyring holds the keys a verifier trusts, and nothing here requires a retired key to remain in one. A deployment that simply removes it reaches the same refusal without the lifecycle format, and S2 below says why both are conformant -- keyring encoding and lifecycle are undefined here. What the format actually buys is a stated reason travelling with the refusal instead of a silent absence. Whether revocation belongs in the profile is a question for the next revision. A related detail of the same format: it carries the public key as an encoded key with no separate curve field, so the crv = 6 requirement of Section 4.1 is checked by inspecting the encoded key, which the reference does.¶
• S2 -- unused keyring entries are shape-checked. The TypeScript reference checks the shape of every static keyring entry before the chain walk -- each value must be a non-empty string -- and refuses the whole keyring if any entry fails, including entries for keys nobody signed with. It does not decode those unused entries as SPKI or as Ed25519 keys, so the divergence is real for an empty or non-string entry and not for a well-shaped but cryptographically malformed one. The other four look only at the key they actually use. Keyring encoding is undefined here (Section 1.5), so both behaviours conform and the two answers are both correct.¶
• S3 -- a non-UTF-8 COSE kid refuses the object. Section 4.1 now requires a verifier not to resolve an identifier through a lossy decode. The reference goes further and refuses the whole envelope, so a deployment using opaque non-UTF-8 identifiers cannot use it at all.¶
• S4 -- deterministic CBOR is enforced envelope-wide. Section 4.1 requires the Core Deterministic Encoding Requirements for the protected header. The reference's decoder applies them to the whole COSE object including the unprotected map, so an envelope this profile permits can be refused for an encoding choice outside the protected bytes.¶
• S5 -- input ceilings that differ, which is not the same as ceilings that are missing. The TypeScript reference fixes a 16 MiB input limit, a JSON nesting depth of 64, a canonicalizer depth of 64 and a CBOR depth of 32. The others are not unbounded: the Go verifier defines its own parser ceiling of 2000 nesting levels (impl-go/parse.go), the C# verifier inherits JsonDocument's default maximum depth of 64, and the Rust verifier relies on serde_json's nesting limit, which its own source names as the control. Python has no explicit gate and stops at the interpreter's recursion limit. So five verifiers enforce four different ceilings, and a document between the tightest and the loosest is refused by some and accepted by others. Section 13 assigns limits to the Deployment and fixes no number here, so every one of them conforms -- which is precisely why the disagreement is a fact about interop rather than a defect in any of them. An earlier draft of this register said the other four had "no equivalent fixed limits"; that was false, and this row is the correction.¶
• S6 -- non-NFC handling. The reference reports non-NFC strings in a warnings channel by default and can be configured to refuse them outright; the other four have no mode and no warning. Section 3.3 permits both, which means the same receipt legitimately receives two different verdicts from two conforming verifiers, and a caller cannot tell which mode produced the one it holds.¶

Divergences among the five that the conformance harness cannot see. The harness compares verdicts over a shared corpus. A behaviour only one implementation has, or that no vector exercises, is invisible to it -- and these were found by reading the five sources against one another rather than by running them.¶

• D1 -- one trust document, two verdicts, and one of them is an accusation. An honest two-receipt chain signed by one key was presented to all five verifiers twice: once with a plain {kid: publicKey} keyring, once with this package's own noa.signing-key-lifecycle/0.1 trust document carrying the same key with retiredAt: null. Plain keyring: VALID in all five. Lifecycle document: VALID in TypeScript, TAMPERED in Python, Go, Rust and C#, the Python reason reading "unknown kid k-life at seq 0". The four do not know the format, read it as a flat map, fail to find the kid, and conclude the receipt was signed outside the trust root -- so a legitimate trust document holding the correct key makes four of five verifiers accuse an honest chain of tampering. It is G6's defect reached through a different input, and the same violation of Section 8.3. No file under conformance/ mentions the format, so no runner ever feeds it to them.¶
• D2 -- one implementation does not state the key-canonicality check. TypeScript, Python, Rust and C# each carry the y >= q rejection in their own source. The Go verifier rejects the eight small-order encodings and has no y-coordinate gate at all, inheriting whatever its standard library does. Section 4.2 makes that rejection a MUST as of this revision, so the Go verifier does not state a check it is now required to make.¶
• D3 -- two implementations have no channel for a required statement. Go and Rust carry no warnings field, so G14, G15 and G16 cannot be satisfied in them without an API change. The corpus compares verdicts, and a missing warning is not a verdict.¶
• D4 -- COSE exists once. The envelope path is implemented only in the TypeScript reference, so nothing on it -- the alg pin, crit handling, deterministic encoding, kid resolution -- has cross-implementation evidence in either direction.¶

What the harness can and cannot settle, stated once. conformance/MATRIX.md is generated from four runs: the TypeScript reference against the Python one, and then the Go, Rust and C# verifiers each against the Python one. The topology is a star with the Python reference at its centre, not five implementations tested against one another -- so a behaviour the Python verifier does not implement cannot be seen by that harness at all, and five-way agreement and five-way nonconformance coexist without contradiction. G1 to G3 are exactly that case: all five agree with each other, and none of them agrees with this document.¶

Two claims in the reference implementation's own comments are retracted by this revision and not yet corrected there. src/cose/receipt-cose.ts calls its output a "COSE_Sign1 Signed Statement" and promises "the external non-equivocation anchor NOA's self-signed chain lacks". Neither survives this revision: Section 4.3 shows what a Signed Statement additionally requires and the register above records that the implementation emits none of it, while Section 7 narrows what registration supplies. A reader who opens the code will find the older wording; it is a comment, not a control, and correcting it is filed.¶

Conformance corpora, counted at the pinned snapshot. conformance/vectors/attack/ 16 files and conformance/vectors/malformed/ 9 (25 adversarial in total); conformance/action-digest/ 33 vectors, 34 in the repository since df777a6; packages/rail-x402/conformance/settlement-evidence/ 72 (1 accept, 57 reject, 14 control); packages/evidence/conformance/ 77 bundles. Alongside them, conformance/golden/ answers a different question: whether a real past release's own signed output still verifies today.¶

What a third party measured. On 27 July 2026 an independent reconciliation implementation ran against this corpus at a pinned commit and reported on the SCITT list (https://mailarchive.ietf.org/arch/msg/scitt/zWZBQXXSGV-vgbTeOLTjlb9DGLg/): 23 of 23 adversarial files then published produced at least one integrity-class divergence, with cross-chain-splice the clean case -- both receipts verify in isolation and the forgery exists only in the set. The same run measured a shared subject digest agreeing with another party's canonicalization corpus on 22 of 22 cases, while a separate ledger-indexing construction that applies Unicode normalization agreed on 20 of 22 under a UTF-16 member sort and 19 of 22 under a code-point sort -- the collisions being invisible without a shared vector, which is the argument Section 10 makes normative. The corpus has since grown from 23 adversarial files to 25.¶

What is still missing. The purpose-specific negative vectors that Section 8, Section 8.2 and Section 9 call for are not in the public corpus, with one exception: the attribution-substitution vector landed at df777a6. The rest -- a controller success with no physical evidence, a controller success against a witness reporting non-completion, same-party evidence presented as independent, a missing signer relationship, a stale or replayed observation, and the positive baselines mirroring each -- remain committed and unwritten, as does a cross-implementation negative for the alg pin.¶

Not implemented, stated plainly. Ten things, so that no reader has to infer them. Item 1 is gap G8 of the register above. Item 2 is permitted but unimplemented; items 3 and 4 are capabilities this profile deliberately excludes (Section 4.2, Section 5.1); the rest are absences with nothing owed against a rule. The distinction is the one Section 8.3 insists on, applied to this section.¶

1. No Signed Statement mode exists anywhere in the reference implementation, on either side. The producer emits {1: -19, 4: kid} and no CWT_Claims (label 15), so what it mints does not meet Section 4.3 and a conforming Transparency Service is entitled to refuse it at registration. The verifier is the other half, and the half a reader is most likely to assume: it ignores label 15 as a non-critical header, and a committed test shows it accepting a protected header carrying a malformed 15: bstr as a perfectly good generic COSE_Sign1. No code path anywhere evaluates a receipt as a Signed Statement.¶
2. Certificate-based key resolution is permitted but not implemented. Section 4.1 lets a deployment carry x5t or x5chain in addition to kid; the verifier ignores both headers and resolves kid alone. Nothing is excluded -- it is simply not built.¶
3. There is no detached-payload mode. The parser requires the payload element to be a byte string and refuses a null one; the producer always attaches. Section 4.2 describes that and nothing more.¶
4. No range-presented verification. Every implementation requires the complete chain from seq == 0; a presentation starting at seq 1 is refused as a missing genesis, not verified as a partial view. Section 5.1 states that as the rule. A verifier that could authenticate a mid-chain range against a trusted anchor is a real capability and this profile does not have one.¶
5. No controller-outcome artifact and no physical-observation artifact. The vocabulary of Section 8.1 for claims 2 and 3 is specification ahead of implementation. The plane that exists is a payment settlement plane over one rail family; it is an instance of the shape (Section 8.2, Section 8.3), not an answer to the actuator case the review thread was about.¶
6. No settlement-evidence enrolment registry at the pinned 4764cab snapshot -- the registry an Evidence Verifier would consult to decide which action classes require settlement evidence. Device enrolment through pairing is a different mechanism and did exist at that snapshot, with its own conformance vectors; this item is not about it. Without the action-class registry, settlement evidence cannot be required, so at this snapshot its absence costs nothing and its presence buys no upgrade. Subsequent implementation work is outside the measurements reported here.¶
7. The relationship signal is not surfaced in bundle verdicts, and no level of this implementation can derive organizational independence at all.¶
8. The bundle verifier never reaches a network service, by design: a verifier that silently depends on a reachable service is not an offline verifier. Anything that would require a live query is therefore outside what one of its verdicts can establish.¶
9. No published reproducible demonstration of registration with an external SCITT Transparency Service.¶
10. The purpose-specific negative vectors of Section 12 are not written, including a cross-implementation negative for the alg pin. The attribution-substitution vector that was open in earlier drafts of this list is no longer among them: it landed at df777a6.¶

The boundary item 1 leaves is worth stating in the sharpest available words: "the signature verifies" and "an RFC 9943 Signed Statement validates" are different properties, and this implementation currently establishes only the first. Closing it is work on both sides -- the producer must emit the protected claims, and the verifier must gain a mode that checks them and refuses a receipt that lacks or malforms them, per Section 4.3 and [RFC9597], Section 2, which defines label 15 as a CWT Claims map that occurs exactly once across the two header buckets.¶

Every one of these is a boundary this document states rather than a gap it hides. Where a reader finds a normative requirement here whose enforcement is on this list, that requirement is a specification for implementers -- including this one -- and not a report of shipped behaviour.¶

13. Security Considerations

Analysis binds every actor. Where a sentence carries a requirement it names its actor; the requirements in this section fall on the Producer (what MUST NOT appear on a receipt), on verifiers (what they MUST NOT report), and on the Relying Party (how results may be read).¶

This profile attests exactly two things: (1) the record is tamper-evident and signature-verifiable under the issuer's key; and (2) the recorded fields -- action, principal class, verdict, and whichever optional members are present -- are bound into that signature. "Policy identity" is one of the optional ones: both carriers may be absent (Section 3.3), and a receipt that omits them records no policy identity at all while remaining conformant. The principal field is a class marker and not an identity: a receipt recording HUMAN names no human, and a relying party MUST NOT read one out of it. It does NOT attest that the recorded inputs are true, complete, or timely (no capture-completeness); that the policy was adequate; that no action occurred outside the instrumented boundary; that the agent was correct, safe, or wise; that a named approver authorized this exact action before it ran; that a controller succeeded; or that any physical effect occurred. These non-goals are NORMATIVE: implementations and relying parties MUST NOT imply the stronger claims from a receipt.¶

Equivocation -- one issuer signing two divergent histories and showing each to a different party -- is not detectable by any check in this profile. Section 5.1 catches a fork only when both branches are presented together, as a duplicate sequence; nothing reaches a branch the prover withholds. Registration in a Transparency Service is a necessary step toward detecting them and is not a sufficient one: detection additionally requires consistency proofs between log states and a party that monitors them (Section 7), neither of which this profile specifies or requires. A deployment that registers and never monitors has an auditable record and no equivocation defence. Identity attribution above key level requires the out-of-band identity manifest. Algorithm-confusion and key-confusion attacks are mitigated by the strict alg = -19 and pinned-curve requirements of Section 4. Raw prompts, tool arguments, and secrets MUST NOT appear on a receipt; only hashes (optionally HMAC for low-entropy values) are carried.¶

The scope of a checkpoint check is the scope of the key that signed it. A checkpoint can reveal truncation relative to itself, and only to the strength of the binding between checkpoint authority and chain. With an identity manifest, that authority is bound to the keys the manifest authorizes for the genesis receipt's agent.id -- a set, not one key (Section 5.2) -- so a re-heading attacker's checkpoint over its own appended head is rejected. WITHOUT a manifest, checkpoint authentication is key-level only: any key the verifier trusts can mint a checkpoint over any head, so a co-trusted key holder can delete the most recent receipts, sign a checkpoint over the truncated head, and obtain a verified tail check over an incomplete chain. A Chain Verifier MUST surface this limitation to the relying party whenever a checkpoint authenticates without a manifest, and MUST NOT report such a result as an unqualified tail-truncation check. Even with a manifest the guarantee is opener-scoped: on a chain carrying more than one agent.id, the opener's checkpoint does not certify a co-agent's tail.¶

A verifier never normalizes a non-NFC string, and this profile sets no default for whether it rejects one (Section 3.3); the analysis below is written for the accepting configuration, and a verifier in the refusing configuration simply never sees the ambiguity. In the accepting configuration, because a non-NFC string is neither normalized nor rejected (Section 3.2, Section 3.3), two receipts may carry agent.id or action.id values that render identically but differ in bytes, and both verify. A verifier configured in the optional refusal mode rejects such a receipt as malformed instead -- which removes the ambiguity for that verifier and for nobody else, since the same bytes still verify elsewhere. Relying parties that match, index, or alert on these fields MUST compare them as bytes. Normalizing at their own layer before comparing is not an equivalent option: it is precisely what collapses two distinct, validly signed identifiers onto one index entry, match or alert subject, which is the collision this paragraph exists to warn about. A relying party MUST NOT assume that visual equality implies byte equality.¶

A trusted key can try to extend someone else's chain, and one condition stops part of it. Every receipt in a chain is individually valid; nothing in a receipt says who is entitled to add the next one. A party holding any key the verifier trusts can therefore append well-formed receipts to another party's chain -- correct prevHash, contiguous sequence, same scope.chain, same tenant -- and, where the appended receipts claim the victim's own agent.id, every condition but one stays silent. The one that fires is chain-key-discontinuity (Section 5.1): those receipts carry a different sig.kid under that same agent.id. A Chain Verifier that omits the check accepts a forged tail as history. Two escapes remain, stated here rather than left for an attacker to find: an attacker who appends under a new agent.id trips no condition at all, because this profile defines no append authority for a chain (Section 5.1, Section 1.5); and an attacker whose second key is registered under the victim's kid defeats a comparison made on identifiers rather than on resolved key material. Where the attacker instead reuses the victim's own agent.id and sig.kid, it is signing with the victim's key, which is a key-compromise problem this profile cannot address.¶

A receipt can be re-wrapped by anyone who holds a trusted key. The payload is self-contained and self-signed, and Section 4.2 permits the outer COSE signer to differ from the native signer. It follows that any party whose key a verifier trusts can take another party's receipt, strip its envelope, and re-emit the same payload under its own outer signature: both signatures verify, because both are genuine. Nothing in the bytes distinguishes the original emitter from a relay. The consequences are bounded but real: the relay cannot alter a field without breaking the native signature, so the content is safe; what it can do is present someone else's record as something it emitted, and -- if the verifier attributes from the outer kid -- have that attribution land on itself. What stops that is the attribution model of Section 6, and it is worth being exact about which half does the work. The manifest binds agent.id to authorized keys and is checked against the native sig.kid, so a relay cannot make itself the agent: the agent claim is carried by a signature the relay did not produce and cannot alter. The relay is not refused for relaying -- Section 6 forbids rejecting a receipt solely because its outer signer is not one of the agent's keys, because relaying is a legitimate presentation. What a verifier MUST NOT do is report the outer signer as the party that made the record. Without a manifest, attribution is key-level only and even the agent claim is unbound. Registration does not help here: a Transparency Service that follows Section 7 will happily register a relayed statement, because every signature in it is valid.¶

Same-party evidence is the forensic trap this profile names rather than solves. A signed outcome produced under the same administrative control as the authorization is not independent evidence, however sound its cryptography; independence is a property of the trust configuration a verifier applies, never of a field a producer writes about itself (Section 6.1). An implementation that renders UNKNOWN as "independent" has defeated the control.¶

Substitution across claim classes is a signature-valid attack. Both the post-execution record presented as authorization and the machine decision presented as human approval (Section 9) carry genuine signatures. An Evidence Verifier that returns one boolean cannot express "signature good, claim wrong". That is a defect in what such a result can tell its reader, not a conformance failure: Section 8.2's claim-class machinery is non-normative in this revision, so nothing here makes a one-boolean result nonconformant. A reader deciding whether to rely on such a verifier should treat the missing distinction as the gap it is.¶

Parsing attacker-supplied input is a cost this profile does not bound. A verifier ingests JSON and CBOR from whoever presents them, and the checks required here -- duplicate-member detection, surrogate validation, canonical re-serialization -- are all performed on that input before anything about it is trusted. This profile bounds exactly one string -- id, at 128 code points (Section 3.1) -- and sets no maximum payload size, nesting depth, member count, or chain length, and a Chain Verifier is additionally required to hold a complete chain from genesis (Section 5.1), which grows without bound. A Deployment MUST impose its own limits and MUST refuse input that exceeds them rather than attempting a partial verification; a limit that is exceeded is not a tampering finding and MUST NOT be reported as one. A deployment that omits limits has a denial-of-service surface, not a correctness problem.¶

An unpinned digest construction is a silent join. Comparing digests produced under different constructions can both miss a real correlation and, where one construction normalizes and another does not, map two different actions onto one value. Section 10 requires the comparison to fail closed and be reported as indeterminate.¶

Absence of scope.tenant is not a tenancy reset (Section 3.3); a verifier that treats it as one accepts a cross-tenant splice that carries no tampering evidence of its own.¶

14. Privacy Considerations

This section addresses the Producer and the Deployment (Section 1.4); verifiers inherit no obligation from it.¶

A receipt is designed to be shown to parties who were not present when the action ran, so what it carries is a privacy decision as much as a security one.¶

Raw parameters are forbidden, not prevented. This profile prohibits a Producer from placing raw prompts, tool arguments, secrets or other sensitive parameters anywhere on a receipt (Section 3), and action.paramsHash carries a digest in place of the values. What the format cannot do is enforce it: several members are unconstrained strings (Section 3.1), so a producer that writes a secret into one produces a receipt every verifier accepts. A deployment handling sensitive parameters therefore needs a producer-side control, and a relying party that needs the parameters must obtain them out of band. Whether it can then open the commitment is a matter for the producer's own contract, not for this profile: Section 3 states that the preimage construction is undefined here, and for the keyed form the key is a tenant secret. So the privacy property is one-directional -- the receipt does not disclose the parameters themselves -- and the verification property it might seem to imply does not follow from this document alone. What the receipt does disclose is set out below: a guessable commitment is an oracle, and the identifiers and timestamps are linkable by design.¶

A hash of a low-entropy value is not a privacy control. Where the committed parameters are guessable -- an amount, a boolean, a small identifier -- SHA-256 is a confirm-by-guess oracle rather than a shield, since anyone can hash a candidate and compare. For those cases the profile provides the keyed form hmac-sha256:<hex> under a tenant-scoped key, which removes the oracle from anyone who does not hold the key. Producers SHOULD use it whenever the parameter space is enumerable, and MUST NOT treat a plain digest of a low-entropy value as a disclosure control.¶

What remains linkable, by design. A receipt still carries scope.chain, agent.id, action.id, action.canonical, timestamps and, where present, governance.approval.by. These are opaque strings to this format, but they are stable across receipts, which is what makes a chain a chain: any party holding two receipts can tell they concern the same chain or the same agent, and timestamps support timing correlation. A Deployment that treats those identifiers as sensitive SHOULD choose opaque, non-descriptive values -- an internal identifier rather than a person's address -- because the format cannot enforce that and a verifier cannot undo a descriptive choice.¶

Registration publishes, to the extent the log retains. Submitting a Signed Statement places it and the CWT Claims in its protected header into an append-only log whose purpose is that third parties can inspect it. How much of the payload they can see is the log's choice, not this profile's. [RFC9943], Section 6.2 contemplates statements whose payload is carried as a hash rather than in full -- and that construction is not conformant with this profile as specified: Section 4.2 requires the receipt itself to be the attached payload, and Section 7 requires a Transparency Service to validate that payload as a receipt and to check sub against its scope.chain. A hash-only statement fails both. A deployment that needs to disclose less therefore cannot get it from this revision; defining a mapping -- what the hash covers, and what a service can still check -- is work for a future one. CWT Claims in COSE headers are not encrypted ([RFC9597], Section 3), so iss and sub are visible to every party that can read the log. A deployment SHOULD decide what may be published before it registers: transparency rests on an append-only sequence, which [RFC9943], Section 5.1.3 requires the log's verifiable data structure to guarantee -- it cannot be modified, deleted or reordered -- so an entry cannot be un-registered, and this document defines no redaction mechanism. What a service retains and serves beyond that history is its own policy, which this profile does not constrain.¶

Signer relationship reporting is a disclosure too. The trust-configuration digests that Section 6.1 requires alongside a derived relationship commit to a policy and a registry snapshot; they do not disclose their contents, and a Producer SHOULD keep it that way rather than inlining registry material into a result a relying party may forward.¶

15. Open questions for the working group

This section is to be removed by the RFC Editor before publication. It records what this revision deliberately did not settle, so that a reader does not mistake an open question for an oversight.¶

• The verification equation is pinned in this revision, and the working group may revisit which one. Section 4.2 pins the cofactorless check together with the canonical signature scalar, the canonical public-key encoding and the rejection of the eight small-order encodings; [RFC8032], Section 8.8 explains in its own words why the choice cannot be left open -- any signature meeting the non-multiplied equation satisfies the multiplied one, so implementations that choose differently disagree about the exact set of valid signatures, and in a hash chain that is a divergent accepted history. This revision therefore chose, rather than leaving validity implementation-defined. What remains genuinely open is which of the two the working group wants. The evidence, taken from this document's own measurements (Section 12, G20): four of the five shipped verifiers were measured cofactorless -- Python, Rust and Go from their sources, and the TypeScript reference through the OpenSSL version it was measured against -- and the fifth could not be measured. So the equation chosen here is the one four of five already implement, and the argument for the other is not "it matches what ships". Either can be made deterministic; neither can be left unmade.¶
• The request signer is defined by example, which is why the text that needs it is not normative. Section 6.1 derives a signer relationship against the request signer, and this document describes that party only by pointing at what the reference implementation signs with. That is one of the reasons the relationship analysis there carries no requirement in this revision. The question for the working group is what a definition would have to fix -- the party, the trust configuration it is derived from, and the digests that identify that configuration -- before the analysis can become a requirement anywhere.¶
• Bare or enveloped? Section 4 admits both forms because both ship. Whether a SCITT-native profile should require the envelope -- making every receipt registrable at the cost of forbidding the bare form every current implementation verifies -- is a genuine fork.¶
• Duplicate sequence numbers, in a future revision. This revision answers the question in the strict direction: a byte-identical duplicate is one of the six chain conditions, so the set fails and a verifier that de-duplicates and returns a positive result is not conformant (Section 5.1). That is deliberately the safe answer rather than the obviously right one -- a retransmitted copy is an innocent event, and refusing it costs an operator something real. Whether a future revision should permit acceptance after de-duplication, and under what reporting requirement, is the open question; it is not open in this one.¶
• Where the Evidence-Verifier layer belongs, now that this revision has stopped requiring it. Section 6.1, Section 8.1, Section 8.2, Section 9 and Section 10 each mark the passages that run over artifacts Section 1.5 lists as undefined, and those passages carry no RFC 2119 requirement here: an implementation cannot fail them. That was the honest answer to an untestable obligation, and it leaves a real question rather than settling it. Either the artifact formats come into this profile and the analysis becomes normative here, or the analysis moves into the companion documents that define them and becomes normative there. What should not persist is the present state, where the reasoning is written in one document and enforceable in none.¶
• Should the two untokenised results be named? Section 1.5 lists them: the conflict result of Section 8.2 and the unproven-authorization result of Section 9. Neither carries a requirement in this revision -- both live in passages marked non-normative -- and neither has a token, so an implementation that reports them chooses its own name and two implementations reporting the same finding will not agree on it. Defining the result and its token together is a small vocabulary decision with a real interoperability consequence, and it is the working group's to make rather than this author's.¶
• "Issuer" is overloaded across three different parties. Section 1.4 aliases the native Producer as the Issuer; Section 4.3 uses iss for the authority the outer Signed Statement is emitted on behalf of; Section 6.1 calls the native signer the issuer; and a relay that wraps someone else's receipt is a fourth party using the same envelope position (Section 13). Nothing here is contradictory, and an implementer can still build from it -- but a reader has to carry the disambiguation in their head, and the ambiguity invites exactly the native/outer collapse Section 6 forbids. Whether these should be distinct named roles, and which of them iss denotes when they differ, is a naming decision with security consequences and it belongs to the working group.¶
• This profile forbids the leap-second representation, and that is a decision to review. Section 3.3 requires a Producer not to emit a date-time whose seconds field reads 60, and a verifier to reject one. The alternative this revision rejected was to admit 60 and require nobody to validate it, which is not implementable offline: [RFC3339], Section 5.7 admits 60 only at an actual leap-second position adjusted by the value's offset, and says future leap seconds cannot be predicted, so a verifier holding no table cannot decide whether such a value is a valid date-time -- and the requirement to reject what is not valid would have no determinate answer. Pinning a table was rejected too: a table is state that ages, and offline verifiers acquire it at different times, so two conforming verifiers would still disagree about a historical instant. Forbidding the representation is the only branch that leaves every verifier the same answer, and it costs a Producer nothing it needs. The working group may prefer one of the branches this revision declined; the cost of each is stated here so the choice can be made on evidence.¶
• Key rotation, and what it currently costs. Section 5.1 requires one key per agent.id within a presented chain, which is what closes the chain-extension attack; the price is stated in Section 5.2: rotation is not expressible inside a chain, so a deployment that rotates a signing key starts a new one. The reference implementation has gone further and refuses a receipt signed by a key its trust document marks retired, which this profile does not require (Section 12). Whether a rotation or revocation mechanism belongs in the profile -- and if so, whether it may relax the one-key rule or must sit beside it -- is a genuine trade between an attack this revision closes and an operational need every deployment eventually has.¶
• Standards Track with no IANA action, or Experimental? The header of this revision reads Standards Track, which is itself a change from -00's Informational (Appendix A); it records the author's current intention, not a decision taken for the working group. Section 16 requests nothing, so there is no media type for the payload, and Section 4.3's content type cannot be interoperable across deployments. Two answers are available and the document does not choose between them: register a media type and stay on the Standards Track, or publish as Experimental while the profile's open questions settle and register later. What would be wrong is to ship a wire format on the Standards Track with neither.¶

16. IANA Considerations

This section carries no normative requirement on any actor.¶

This document has no IANA actions in this revision, and one of those absences is load-bearing: without a registered media type for the action-receipt payload, the content type of Section 4.3 cannot be interoperable across deployments. A future revision ought to register one, and a Standards Track document that carries a wire format arguably should not ship without it -- this revision states the gap rather than papering over it. It uses the existing IANA COSE Algorithms registry value -19 (Ed25519) and the existing COSE/CWT header parameters. The vocabularies named in Section 6.1, Section 8.2, and Section 8.3 are shared spellings for reporting, not an interoperable output format -- this revision defines no result schema (Section 1.5), so two implementations using the same word still do not produce comparable output -- and they are not proposed for registration in this revision. A future revision could request registration of a media type for the action-receipt payload and/or of CWT or COSE claims for the payload fields.¶

Appendix A. Changes since -00

This section is to be removed by the RFC Editor before publication.¶

This revision exists because of a public review thread. What follows is that story in order: what was asked, what was built and measured in answer, and what this document now guarantees. Every difference between the posted -00 and this text is accounted for here -- a reader diffing the two should find no change this section does not explain.¶

Appendix B. Acknowledgments

This revision is the product of a public review thread on the SCITT mailing list in July 2026, archived at https://mailarchive.ietf.org/arch/browse/scitt/?q=noa-scitt-ai-agent-receipt. The reviewers named here disagreed usefully, contributed concrete text, and in one case ran their own implementation against this profile's adversarial corpus rather than arguing about it. Errors that remain are the author's.¶

• Carlos Hernandez separated a controller's report from the physical effect and asked for a machine-checkable non-claim rather than a caveat in prose: Section 8.1, Section 8.2 and Section 8.4.¶
• Iman Schrock (EMILIA Protocol) put pre-execution authorization in front of both other claims, supplied the substitution negative case, argued the signer relationship belongs in a field, and cautioned against treating two digest constructions as equal without a shared vector: Section 9, Section 6.1 and Section 10.¶
• Steven Mih held the thread to shared conformance vectors rather than shared vocabulary alone, which is the discipline Section 12 commits to.¶
• Joel Hillier (Certisyn, Inc.) ran an independent reconciliation implementation against the published corpora and reported the numbers, including the failure no per-receipt verifier can reach: Section 5.1, Section 3.2 and the indeterminate-control discussion in Section 10.¶

Author's Address