NordenSoft

Denmark hello@ordeliya.com

Security Network Working Group AI agent correlation digest domain separation authorization provenance accountability human approval 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.

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

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. is written to be attacked, and 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.

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 or in 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 — 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 — this document says so at the point of use and states the residual, rather than implying an enforcement that does not exist.

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

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.

Construction The construction is fixed and is reproduced here in full; it is a SHA-256 value over RFC 8785 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 for the exact anchor and the measurement date. " } ]]> 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 : 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. is written accordingly: there is no digest artifact to authenticate, and therefore none to substitute.
• 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.

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.

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 ). 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 . 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 ) 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 (). 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 ) the same nonce is also the derivation's seed, so P4 carries that profile's unguessability as well — one requirement, two loads. See 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. carries the residual. See 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 and is stated separately because it is the property retries break.

Status of the construction's open items

Item	Status
exact member names and their order	RESOLVED — , ten members, order irrelevant under JCS
encoding of the digest input (JCS vs CBOR)	RESOLVED — JCS
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 ). See .
the nonce's entropy source	RESOLVED as a producer obligation — see P4 in and . Entropy is unverifiable from the value, so this closes as a documented obligation with a disclosed residual, never as a vector-enforced control.

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.
• 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. 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 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 . 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 transports it through the user agent (, 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.

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

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.

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.

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

Substitution and replay

• Digest substitution. An attacker who can alter the digest before it is embedded breaks correlation. Under mode (a) of , 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 (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 . Without domain separation a digest could be presented as another artifact's hash or signature pre-image.

Privacy Under mode (a) of 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 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.

IANA Considerations [PLACEHOLDER — pending working group direction]. The provisional intent:

• Media type registration () for the digest's carrier artifact, provisionally application/noa-action-digest+json, and — if a COSE profile (, ) 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 ), 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 ().
• No OAuth registry action. 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.

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.

References Normative References National Institute of Standards and Technology Informative References NordenSoft

Implementation status This section is to be removed before publication as an RFC, per . 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:

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