Internet-Draft NOA Action Digest August 2026
Toraman Expires 15 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-toraman-noa-action-digest-01
Published:
Intended Status:
Standards Track
Expires:
Author:
T. Toraman
NordenSoft

The NOA Action Digest: a Domain-Separated Correlation Value for Human-Approved Agent Actions

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.

▲

Table of Contents

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.

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:

  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.

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:

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.
  • 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

Table 1
Item Status
exact member names and their order RESOLVED — Section 4, ten members, order irrelevant under JCS
encoding of the digest input (JCS vs CBOR) RESOLVED — JCS [RFC8785]
the domain-tag string RESOLVED — NOA-ActionDigest-v0.1-dig
whether the digest object is itself signed, or purely derived RESOLVED — purely derived, {spec, digest}, no sig
test vectors RESOLVED — the Copenhagen vectors, conformance/action-digest/vectors.json
whether a rail-binding component (chain id, contract, payer) is inside the digest or carried separately RESOLVED — the projection is frozen at ten members; it carries a chain member (a tenancy/record-chain identifier) but no ledger/rail chain id, no token contract and no payer. A rail binding is therefore carried outside this digest, and in the profile the reference implementation ships it is carried twice: by the mandate's Parameter Commitment, and as inputs to the derivation that consumes this digest and produces the value the rail actually carries (mode (b) of Section 5). See [I-D.toraman-noa-settlement-evidence].
the nonce's entropy source RESOLVED as a producer obligation — see P4 in Section 4.2 and Appendix A. Entropy is unverifiable from the value, so this closes as a documented obligation with a disclosed residual, never as a vector-enforced control.

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:

Both modes are subject to:

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.

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.

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.

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, 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:

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

[FIPS180-4]
National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, , <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/info/rfc8785>.

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, , <https://datatracker.ietf.org/doc/draft-toraman-noa-settlement-evidence/>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/info/rfc9052>.
[RFC9053]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, , <https://www.rfc-editor.org/info/rfc9053>.
[RFC9396]
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, , <https://www.rfc-editor.org/info/rfc9396>.
[RFC9942]
Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, , <https://www.rfc-editor.org/info/rfc9942>.

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.

The following were measured, in that repository, on 2026-08-14, at main commit 7aa8e37:

Author's Address

Tora Toraman
NordenSoft
Denmark