Network Working Group T. Toraman Internet-Draft NordenSoft Intended status: Standards Track 14 August 2026 Expires: 15 February 2027 The NOA Action Digest: a Domain-Separated Correlation Value for Human- Approved Agent Actions draft-toraman-noa-action-digest-01 Abstract This document defines a domain-separated correlation value, the NOA Action Digest, that binds a verified human authorization for an agent action to the artifacts and external events associated with that action's execution attempt. The digest is a fixed-width value derived from an approved action's authorization record, its tenancy and chain identifiers, its parameter commitment, its execution grant, and a single-use nonce. It is designed to be embedded in external systems that carry an opaque, caller-chosen identifier, so that a third party can correlate an external event with a specific prior authorization. *The digest establishes correlation only. Equality of digests is not evidence that any statement made by any party about the action is true, and is not evidence that any action was executed or any effect occurred.* 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 15 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Toraman Expires 15 February 2027 [Page 1] Internet-Draft NOA Action Digest August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Verification philosophy . . . . . . . . . . . . . . . . . 3 1.2. Editorial note on this revision . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. The Frozen Base Record Is Not Modified . . . . . . . . . . . 5 4. Construction . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Required commitments . . . . . . . . . . . . . . . . . . 6 4.2. Properties required by this document . . . . . . . . . . 6 4.3. Status of the construction's open items . . . . . . . . . 7 5. Embedding in External Systems . . . . . . . . . . . . . . . . 8 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. What the digest does not establish . . . . . . . . . . . 11 7.2. Residual trust anchors . . . . . . . . . . . . . . . . . 12 7.3. Substitution and replay . . . . . . . . . . . . . . . . . 13 7.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Implementation status . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Autonomous software agents increasingly take actions with external consequences. Systems that require a human to approve such actions produce a record of the approval, but that record and the action's later effects are usually correlated only by trusting an intermediary's bookkeeping. Toraman Expires 15 February 2027 [Page 2] Internet-Draft NOA Action Digest August 2026 This document defines a value whose derivation is fixed, public, and reproducible from the authorization record itself, so that correlation does not depend on any intermediary's assertion. The value is designed for the common pattern in which an external system carries a caller-chosen opaque field that it commits to but does not interpret. This document deliberately does *not* define an execution binding. Correlating an authorization with an external event is strictly weaker than establishing that the approved action was performed. Section 7 states the boundary. *Non-goal:* this document does not define, and its authors do not claim, any mechanism that prevents a sufficiently capable adversary from causing harm. It defines a value that makes certain classes of substitution detectable after the fact. 1.1. Verification philosophy This document is written under a discipline its authors call the *Copenhagen model*: a verifier never states what happened; it states what the supplied evidence supports, and it records, in the same breath and on every surface, what it does *not* claim. Every section below that names a control also names the residual the control leaves behind. Where a control does not exist, this document says so rather than describing an intention as a property. Section 7 is written to be attacked, and Section 7.2 is deliberately an open list rather than a taxonomy. The name is a nod to a remark about physics — that the subject concerns what we can _say_ about nature — attributed to Niels Bohr, secondhand, via Aage Petersen's 1963 recollection; it does not appear in Bohr's own writings, and this document claims no more for the attribution than that. The authors' own sentence for the same idea carries no attribution at all: _we do not tell you what happened; we show you what the evidence proves._ 1.2. Editorial note on this revision _This subsection is non-normative and is to be removed before publication as an RFC._ Two conditions govern the release of this document, and they are stated here so that a reader holding a revision can check them mechanically: Toraman Expires 15 February 2027 [Page 3] Internet-Draft NOA Action Digest August 2026 1. This document is not submitted while any placeholder-marked item in Section 4 or in Section 7 is unresolved. *No such item is open in this revision.* Exactly one _unresolved_ item remains anywhere in this document — the registry request awaiting working-group direction in Section 8 — and this condition does not cover it. 2. No claimed defence is submitted without a conformance vector that enforces it. A stated requirement on an unimplemented interface is a request, not a control, until a conformance vector enforces it. Where a property is not vector-enforceable at all — see P4 in Section 4.2 — this document says so at the point of use and states the residual, rather than implying an enforcement that does not exist. 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. * *Authorization Record* — a signed statement that a named principal approved a specific action under stated bounds. In the reference implementation this is a noa.receipt/0.1 whose governance verdict is ALLOWED. *The record names the approving principal in a field; it is signed by the issuing gate's key, which is not the same thing.* The signature establishes that the gate issued and has not since altered the record — not that the named human held any key, and not who physically approved. Which identity a deployment binds to the approval, and how, is outside this document; see Section 7.1. * *Parameter Commitment* — a cryptographic commitment to the canonical byte encoding of the action's parameters. In the reference implementation this is action.paramsHash. * *Execution Grant* — a single-use, time-bounded authorization to perform one execution attempt of one committed action. * *Action Digest* — the value this document defines. * *Correlation* — the property that two records refer to the same authorized action. *Correlation is not attestation.* * *Relying Party* — any party that verifies these artifacts. A Relying Party is assumed to trust neither the agent nor the operator of the approval system. Toraman Expires 15 February 2027 [Page 4] Internet-Draft NOA Action Digest August 2026 3. The Frozen Base Record Is Not Modified The Authorization Record format assumed by this document is frozen and MUST NOT be modified to carry an Action Digest. Implementations MUST NOT add a member to the Authorization Record at any depth. The Action Digest is carried in separate, referencing artifacts. _Implementation note, non-normative:_ in the reference implementation the record schema sets additionalProperties:false at the root and on every nested object, and lists all root members as required (schema/ noa-receipt-0.1.schema.json), so a new member is rejected twice. Adding one would change canonical bytes, record hashes, signatures, chain links, checkpoints and every published conformance vector. 4. Construction The construction is fixed and is reproduced here in full; it is a SHA-256 [FIPS180-4] value over RFC 8785 [RFC8785] canonical JSON. The reference corpus that enforces it is the *Copenhagen vectors* — the cross-language conformance corpus published with the reference implementation, at conformance/action-digest/vectors.json. See Appendix A for the exact anchor and the measurement date. projection = a JSON object with EXACTLY these ten string members: spec, authorizationReceiptHash, tenant, chain, actionId, actionCanonical, actionParamsHash, executionGrantId, executionGrantHash, executionNonce JCS = RFC 8785 canonical JSON of the projection PREIMAGE = UTF8("NOA-ActionDigest-v0.1-dig:") || SHA-256(JCS) ; 26 + 32 = 58 bytes DIGEST = "sha256:" || lowercase-hex(SHA-256(PREIMAGE)) wire form: { "spec": "noa.action-digest/0.1", "digest": "sha256:<64 lowercase hex>" } Four properties of the construction that a reviewer will ask about, answered rather than deferred: * *The domain tag ends in -dig, not -sig.* This value is hashed and *never signed*, so it is kept out of the signing namespace: a -sig tag here would create a signing pre-image some other verifier might one day be persuaded to accept. _(Consequence for Section 8: a registry named for *signing* domains does not fit a *hashing* tag.)_ * *The digest object is not signed.* It is a derived value, recomputed by the verifier from the Authorization Record and the Execution Grant. Section 6 is written accordingly: there is no digest artifact to authenticate, and therefore none to substitute. Toraman Expires 15 February 2027 [Page 5] Internet-Draft NOA Action Digest August 2026 * *Member order is irrelevant* because JCS sorts names; the _named slots_ are what prevent a transposition of actionId and actionCanonical from colliding (vector reject-action-fields- transposed). * *The two hash rules inside the projection are deliberately different* and must not be interchanged: authorizationReceiptHash is the receipt-reference rule, executionGrantHash the side- artifact rule. 4.1. Required commitments The digest input MUST commit to at least the following: 1. the *locally recomputed and verified* Authorization Record hash — not a hash asserted by a third party; 2. the tenant identifier; 3. the chain identifier; 4. the action identifier; 5. the action's canonical name; 6. the Parameter Commitment; 7. the Execution Grant identifier and/or its hash; 8. a single-use execution nonce, carried inside the signed Execution Grant. The nonce is signed *by being a member of the signed grant*, not by carrying a signature of its own. 4.2. Properties required by this document * *P1 — Width.* The digest MUST be exactly 32 octets. _Rationale:_ the external carrier fields this document targets are 32-octet opaque values (see [I-D.toraman-noa-settlement-evidence]). A construction of any other width cannot be embedded without a lossy transformation, and a lossy transformation destroys the correlation. _Scope, because it is narrower than it looks:_ this rationale binds *mode (a)* of Section 5. Where a profile uses the digest as an input to a derivation whose _output_ is carried instead (*mode (b)*), the carried value's width is set by that derivation, not by this property. P1 is retained unchanged because this document does not restrict a profile to one mode, and a fixed width is what keeps the two modes interchangeable. * *P2 — Domain separation.* The digest MUST be computed under a domain tag distinct from every other signing or hashing domain the producing system uses, so that a digest can never be replayed as, or confused with, another artifact's signature pre-image or reference hash. * *P3 — Determinism.* The digest MUST be re-derivable, byte- identically, by any party holding the same inputs, with no dependence on wall-clock time, iteration order, locale, or floating-point behaviour. Toraman Expires 15 February 2027 [Page 6] Internet-Draft NOA Action Digest August 2026 * *P4 — Unguessability.* The digest MUST NOT be guessable by a party that does not hold the input preimage. The single-use nonce (item 8 of Section 4.1) MUST contribute at least 128 bits of entropy from a cryptographically secure source. _Rationale:_ the digest, or a value derived from it, becomes public when embedded in an external system (Section 5). If the other inputs are low-entropy or enumerable, a public digest permits confirm-by-guess disclosure of the action's parameters. Under a derivation profile (mode (b) of Section 5) the same nonce is also the derivation's seed, so P4 carries that profile's unguessability as well — one requirement, two loads. See Section 7.4 for where each lands. *P4 is not verifiable from the value.* Entropy is a property of the _generator_, not of 32 octets: no relying party and no conformance vector can distinguish a CSPRNG digest from a counter by inspection. P4 is therefore stated as a *producer obligation with a disclosed residual*, and a conforming implementation MUST document the nonce source. Section 7.4 carries the residual. See Appendix A for the reference implementation's measured nonce source. - *P5 — Ordering.* The digest MUST be computable *before* the execution attempt is dispatched. Any construction requiring an input that exists only after dispatch is out of scope, because a value that cannot be committed before dispatch cannot correlate a pre-committed authorization with a post-dispatch event. This is enforced *by construction* — every one of the projection's ten members exists at approval time — not by a conformance vector, and is stated here as such. - *P6 — Not the parameter commitment.* The Action Digest MUST NOT be the Parameter Commitment, and no document may name the Parameter Commitment as the action digest. _Rationale:_ a parameter commitment does not bind the complete authorization, tenant and chain, the exact attempt, the grant, or the nonce, and it may repeat across retries. This is a naming prohibition on other documents; no conformance vector can enforce it, and it is stated here as a residual, not a control. - *P7 — Uniqueness across retries.* Two distinct execution attempts of the same action MUST yield distinct digests. This follows from item 8 of Section 4.1 and is stated separately because it is the property retries break. 4.3. Status of the construction's open items +==============+=================================================+ | Item | Status | +==============+=================================================+ | exact member | *RESOLVED* — Section 4, ten members, order | | names and | irrelevant under JCS | | their order | | +--------------+-------------------------------------------------+ | encoding of | *RESOLVED* — JCS [RFC8785] | Toraman Expires 15 February 2027 [Page 7] Internet-Draft NOA Action Digest August 2026 | the digest | | | input (JCS | | | vs CBOR) | | +--------------+-------------------------------------------------+ | the domain- | *RESOLVED* — NOA-ActionDigest-v0.1-dig | | tag string | | +--------------+-------------------------------------------------+ | whether the | *RESOLVED* — purely derived, {spec, digest}, no | | digest | sig | | object is | | | itself | | | signed, or | | | purely | | | derived | | +--------------+-------------------------------------------------+ | test vectors | *RESOLVED* — the Copenhagen vectors, | | | conformance/action-digest/vectors.json | +--------------+-------------------------------------------------+ | whether a | *RESOLVED* — the projection is *frozen at ten | | rail-binding | members*; it carries a chain member (a tenancy/ | | component | record-chain identifier) but *no* _ledger/rail_ | | (chain id, | chain id, *no* token contract and *no* payer. | | contract, | A rail binding is therefore carried *outside* | | payer) is | this digest, and in the profile the reference | | inside the | implementation ships it is carried twice: by | | digest or | the mandate's Parameter Commitment, and as | | carried | inputs to the derivation that consumes this | | separately | digest and produces the value the rail actually | | | carries (mode (b) of Section 5). See | | | [I-D.toraman-noa-settlement-evidence]. | +--------------+-------------------------------------------------+ | the nonce's | *RESOLVED as a producer obligation* — see P4 in | | entropy | Section 4.2 and Appendix A. Entropy is | | source | unverifiable from the value, so this closes as | | | a documented obligation with a disclosed | | | residual, never as a vector-enforced control. | +--------------+-------------------------------------------------+ Table 1 5. Embedding in External Systems An Action Digest MAY reach an external system in either of two modes, and the difference decides what becomes public: * *mode (a) — direct embedding.* The digest itself is placed in the external system's caller-chosen opaque identifier field. Toraman Expires 15 February 2027 [Page 8] Internet-Draft NOA Action Digest August 2026 * *mode (b) — derivation input.* The digest is one committed input to a derivation whose *output* is placed in that field. *Under mode (b) the digest itself never reaches the external system*, and the carried value binds whatever else the derivation commits to. [I-D.toraman-noa-settlement-evidence] defines such a profile, and it is the one the reference implementation ships. Both modes are subject to: * *E1* — the external system MUST commit to the field in a way *no party in the dispatch path* can alter after the embedding party signs (for example, by including it in a signed structure the external system independently verifies). The threat this addresses is an *intermediary in the dispatch path* — a facilitator, a relay — not the embedding party's own choice of value before signing. Under mode (b) E1 binds the *carried value*; the digest itself is protected only by whatever protects the derivation's inputs, which is the embedding party's own custody of its documents and not the external system. E1 constrains a *third-party* external system's behaviour, so no conformance vector in this corpus can enforce it — it is a residual on the deployment, not a control this document verifies. * *E2* — the external system MUST NOT require the field to be produced by a generation process it names, registers or attests. Where a system requires only _uniqueness_, a deterministic digest satisfies it. Under P4 of Section 4.2 the digest is a SHA-256 image over a pre-image carrying at least 128 bits of cryptographically secure entropy, so *no statistical inspection of the field distinguishes it from a freshly drawn random value* — and this holds for a mode-(a) digest and a mode-(b) derived value alike; a system that merely inspects the field for apparent randomness is satisfied by either. What no such value can satisfy, in *either* mode, is a system that requires a *named generator* — that the field be produced by a named, registered or attested process rather than merely appear random — because neither value was drawn from one. That kind of system is out of scope in both modes. This is not vector-enforceable — no conformance vector can inspect a producer's generator — and is stated here as a residual, not a control. * *E3* — the embedding party MUST treat *the value it places in the external system* as public from the moment it leaves the embedding party's control, and MUST apply Section 7.4. Under mode (a) that value is the digest. Under mode (b) the digest does not become public by embedding — but it becomes *recomputable* by every party handed the derivation's inputs, and the embedding party MUST treat that disclosure as equally permanent. *Note either may be earlier than dispatch:* a profile that projects the digest into an OAuth authorization_details entry [RFC9396] transports it _through the Toraman Expires 15 February 2027 [Page 9] Internet-Draft NOA Action Digest August 2026 user agent_ ([RFC9396], Section 12), so under that projection the digest is public at *authorization-request* time, to every party in the browser path, *before the payment is signed* — and it is public there in mode (b) too, because that projection carries the digest itself rather than a derived value. A profile that puts either value in a user-agent-visible channel MUST say so. Like E1 and E2, E3 is an obligation on the embedding party and its deployment, not a property any conformance vector can check — stated at the point of use as a residual. 6. Verification A Relying Party verifying a correlation claim MUST: 1. verify the Authorization Record's signature against a trust anchor it holds independently, and recompute its hash locally rather than accepting an asserted hash; 2. verify the Execution Grant and its bindings to that record; 3. recompute the Action Digest from the construction in Section 4, building the projection *from the authenticated documents themselves* — the tenant and chain members take the values those documents carry; 4. *separately*, compare the projection's resulting tenant and chain against the Relying Party's *own* expected values, and fail on any difference. This is a distinct step from step 3 and MUST NOT be folded into it: substituting the expected values _into_ the recomputation would make the digest agree by construction and destroy the check. The two steps answer two different questions — step 3 asks _"what do these documents say?"_, step 4 asks _"are these documents mine?"_ — and only the second is a defence against a genuine, correctly-signed bundle belonging to another tenant or another chain; 5. compare the recomputed digest to the value observed in the external system; 6. on any mismatch, return a distinct, machine-readable failure — MUST NOT collapse a digest mismatch into a generic invalid result. Steps 1 and 2 are *not optional and not reorderable*, and the reference implementation pins that as a permanent test rather than asserting it: the digest construction *verifies no signature*, so a fully forged pair — an attacker's key claiming the victim's kid, a record asserting an approved transfer, a grant signed with 64 zero bytes — is *ACCEPTED* by step 3 and *REFUSED* by the record's own chain verification against an honest keyring. *A green step 3 over unverified documents establishes nothing.* Toraman Expires 15 February 2027 [Page 10] Internet-Draft NOA Action Digest August 2026 In-realm recomputation is *not* a trust boundary. A verifier that recomputes inside a runtime an adversary can influence has moved the trust anchor, not removed it. A Relying Party MUST NOT conclude from a successful comparison that the action was performed, that any effect occurred, or that any statement about the action made by any party is true. See Section 7.1. 7. Security Considerations This section is written to be attacked. Where a control does not exist, this document says so rather than describing an intention as a property. 7.1. What the digest does not establish Digest equality is *linkage and correlation only*. It is not proof that a controller claim, a physical claim, a delivery claim, or any other statement about the action is true. It is not an execution binding. A system built on this document establishes that *a key the Relying Party's own keyring trusts signed an Authorization Record carrying this parameter commitment, and that the Execution Grant's own signature is authentic*; it does *not* establish that _that intent is what executed_. *Say exactly what the authenticating entry point checks, because a partial check described as a whole one is worse than none.* The reference entry point (verifyActionDigest) verifies the record chain and the Execution Grant's Ed25519 signature against a keyring the Relying Party holds independently. It does *not* check the grant's authorization _semantics_: the signer's type and role, the signing key's activation window, the grant's expiry, and the envelope reference chain are *not* evaluated here — they belong to the full artifact verifier (verifyArtifact in the reference implementation), which this entry point has no dependency edge to. A caller enforcing an authorization decision MUST run that full verifier as well. Consequently this entry point alone does *not* establish that the key was authorized *at the time of the action* — it checks signature authenticity, never key activation or grant expiry. It also does not establish _which human_ held the key; the approval's subject field is an opaque identifier, not an identity; and a device that signs without opening produces evidence indistinguishable from a device that opened, read and approved. Toraman Expires 15 February 2027 [Page 11] Internet-Draft NOA Action Digest August 2026 7.2. Residual trust anchors A digest does not reduce the following. This is an *OPEN list of the largest known classes, never an exhaustive attack surface*; at least seven further classes are omitted or collapsed by it, including *availability and denial of service*, *replay and rollback*, *verifier defects*, *revocation and recovery*, *privacy leakage*, *cross-tenant isolation* and *supply-chain compromise* — four of which are live in this document and its companion. Each entry below is named permanently, on every surface where this mechanism is described, because each leaves the correlation intact while defeating a guarantee a reader might infer from it. Note also that these anchors do *not* all leave third-party- verifiable evidence: infrastructure-root compromise can alter or suppress evidence, stolen keys produce apparently-valid evidence, and an ungated action produces no evidence at all — *including no record of its absence*. 1. *Infrastructure root.* Compromise of the host or operating system running the approval system defeats every in-process control. Detection depends on evidence leaving the host. 2. *Key custody.* A party that can read a signing key can produce artifacts indistinguishable from genuine ones. *No claim of unforgeable authority may be made for a deployment whose signing key is held in the process the signed artifacts are meant to defend.* See Appendix A for the reference implementation's measured status against this anchor. 3. *Governance capture.* A correctly signed decision made under a corrupt policy is cryptographically valid and substantively wrong. Signatures authenticate authorship, never wisdom. 4. *The deceived approver.* Nothing here proves the approving human understood what they approved, or that an accurate description was rendered to them. This mechanism produces evidence about an approval; it does not prevent a person from being misled into giving one. 5. *Cross-action composition.* Individually approved actions may compose into an outcome no approver sanctioned. Per-action binding says nothing about sequences. 6. *The ungated surface.* Anything not routed through an enforced adapter is outside coverage entirely and produces no artifact at all — including its absence. *Activity outside enforced gateways is outside coverage.* This is a scope statement, not a mitigation, and it is stated with no justifying clause. Model sandbox escapes fall inside it. Toraman Expires 15 February 2027 [Page 12] Internet-Draft NOA Action Digest August 2026 7.3. Substitution and replay * *Digest substitution.* An attacker who can alter the digest before it is embedded breaks correlation. Under mode (a) of Section 5, E1 is the only defence; where the external system does not cryptographically commit to the field, correlation via that system is worth nothing and MUST NOT be claimed. Under mode (b) the substitution is additionally detected on the verifier's side — a digest altered before derivation produces a carried value that no longer equals the one recomputed from the verified documents — but E1 remains required, because detecting a broken correlation is not the same as having one. * *Replay across attempts.* Prevented by P7 of Section 4.2 (per- attempt nonce). A construction without a per-attempt nonce permits an old authorization to be presented as correlating to a new event. * *Cross-domain replay.* Prevented by P2 of Section 4.2. Without domain separation a digest could be presented as another artifact's hash or signature pre-image. 7.4. Privacy Under mode (a) of Section 5 the digest becomes a permanent public correlator. Under mode (b) it does not — but the analysis does not simply improve, it *moves*, and both halves have to be stated or the improvement is oversold. 1. *Confirm-by-guess, mode (a).* If the digest inputs are enumerable, an observer can test candidate parameter sets against the public digest. P4 of Section 4.2 is the mitigation and it is load-bearing, not hygiene. 2. *Confirm-by-guess, mode (b) — closed against an outside observer, by the seed rather than by this document.* The carried value's pre-image contains the derivation's seed, so an observer of the external system holds a value it cannot test a candidate parameter set against, and cannot recover the digest from. What is doing the work is the seed's secrecy, not the digest's construction; the protection therefore lasts exactly as long as the seed is withheld, and not one moment longer. 3. *Disclosure by evidence sharing — unchanged in kind, and larger under mode (b).* Handing a third party the material needed to recompute the digest permanently grants them the ability to locate the corresponding external event. *A relying party receiving an evidence bundle gains a durable capability, not a one-time view.* Under mode (b) that material necessarily includes the derivation's seed, so the same disclosure also hands over the only thing standing between the bundle holder and item 2 — the outside observer's closed channel is open to every bundle holder, Toraman Expires 15 February 2027 [Page 13] Internet-Draft NOA Action Digest August 2026 permanently, before or after the external event exists. Implementations SHOULD make this explicit to the approving human before the first embedding, and SHOULD NOT embed digests for actions whose existence is itself sensitive. 8. IANA Considerations [PLACEHOLDER — pending working group direction]. The provisional intent: * *Media type registration* ([RFC6838]) for the digest's carrier artifact, provisionally application/noa-action-digest+json, and — if a COSE profile ([RFC9052], [RFC9053]) of this artifact is adopted — application/noa-action-digest+cose. * *A registry for NOA signing-domain tags*, policy _Specification Required_. *Rationale:* domain separation is the core anti-cross- protocol mechanism (P2 of Section 4.2), and today the uniqueness of those tags is asserted only in the reference implementation's source. A registry is the correct home for a value whose whole purpose is global distinctness. Note that a registry named for _signing_ domains does not, without widening, accommodate this document's _hashing_ tag. * *No COSE header label is requested by this document.* Were one needed later, the COSE Header Parameters registry policy is _Standards Action With Expert Review_ for 1-255, _Specification Required_ for 256-65535, and _Expert Review_ above 65535; the highest currently assigned integer label is 396 ([RFC9942]). * *No OAuth registry action.* [RFC9396] registers the authorization_details parameter and related metadata, but *type values are not IANA-registered*: Section 2.1 only *RECOMMENDS* that type identifiers be collision-resistant, and Section 14 creates no type registry — so there is nothing to register for an authorization_details projection of this digest. 9. Change log [[RFC EDITOR: please remove this section before publication.]] Changes since -00: author metadata completed (country, explicit submission date). No technical changes; every normative statement, conformance count and reference is byte-identical to -00. 10. References 10.1. Normative References Toraman Expires 15 February 2027 [Page 14] Internet-Draft NOA Action Digest August 2026 [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 10.2. Informative References [I-D.toraman-noa-settlement-evidence] Toraman, T., "Settlement Evidence for Human-Approved Agent Payments", Work in Progress, Internet-Draft, draft- toraman-noa-settlement-evidence-00, 2026, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . Toraman Expires 15 February 2027 [Page 15] Internet-Draft NOA Action Digest August 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . Appendix A. Implementation status _This section is to be removed before publication as an RFC, per [RFC7942]._ A zero-runtime-dependency reference implementation, together with the *Copenhagen vectors* — the cross-language conformance corpus this document's construction is enforced by — is available under the Apache-2.0 license at https://github.com/NordenSoft/noa (https://github.com/NordenSoft/noa). The following were measured, in that repository, on 2026-08-14, at main commit 7aa8e37: * The digest construction and its normative prose: docs/action- digest-spec.md; implementation src/action-digest.ts. * The Copenhagen vectors for this document: conformance/action- digest/vectors.json — 33 cases, 1 ACCEPT and 32 REJECT, generated from fixed seeded keys, each rejection pinning the substring of the refusal reason it measures. Named cases include cross-tenant replay, cross-chain replay, retry non-collision, field transposition, wrong-domain-tag, no-domain-tag, and a /0.2- spelled-as-/0.1 refusal. Toraman Expires 15 February 2027 [Page 16] Internet-Draft NOA Action Digest August 2026 * The knockout sweep over those controls, stated exactly rather than rounded up: *eight* Action Digest controls are registered in the repository's control-knockout registry (scripts/lint-control- knockout.mjs) and are proven to turn a named vector red when the control is removed — the ALLOWED-verdict requirement, the blank- scope-identifier refusal, chain authentication, grant-signature verification, the closed sig object, authorization selection by grant binding, the expected-tenant/chain check, and domain separation. *Not all 32 rejections are knockout-gated, and the gap is structural rather than an omission:* the registry records that the projection's actionId, actionCanonical, actionParamsHash, executionGrantId and executionNonce members cannot be isolated, because authorizationReceiptHash and executionGrantHash are hashes over the whole receipt and the whole grant — any mutation that moves one of those five moves a whole-document hash too, so the attack is refused either way and a knockout that "passed" for that reason would be vacuous. * P4's nonce source: the single-use nonce is the Execution Grant's nonce. The grant schema pins it to ^[0-9a-f]{64}$ (packages/ approval-artifacts/schema/noa-execution-grant-0.1.schema.json) and the gate generates it as 32 CSPRNG bytes rendered as 64 lowercase hex (packages/gate/src/trust.ts), refusing loudly rather than minting a nonce that fails that pattern. That is 256 bits against P4's 128-bit floor. *This is a producer property, not a verifiable one:* a conforming verifier cannot distinguish this generator from a counter, which is why P4 is written as an obligation with a disclosed residual. * Mode (b) of Section 5: the reference implementation carries a *derived* value on its target rail, never this digest — packages/ rail-x402/src/correlation-nonce.mjs performs the derivation and packages/rail-x402/src/settlement-evidence.mjs recomputes it during verification. The Execution Grant nonce measured above is that derivation's seed, so the one measurement carries both of the loads P4 names. * Key custody, anchor 2 of Section 7.2: the reference implementation documents its own open weakness in NON-CLAIMS.md — the execution- grant signing key is held as a string in the process the grants are meant to defend. No claim of unforgeable authority is made for it until that key leaves the process and the signer validates approval proof per signature. Author's Address Tora Toraman NordenSoft Denmark Email: hello@ordeliya.com Toraman Expires 15 February 2027 [Page 17]