Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)

Introduction As autonomous and semi-autonomous agents begin to take irreversible external actions -- moving funds, changing records, releasing data, invoking privileged APIs -- relying parties increasingly demand a verifiable artifact answering "was this exact action authorized, and by whom?" The IETF community has responded with a cluster of receipt formats, each answering one facet:

Identity -- who or what the agent is.
Delegation -- that the agent was authorized to act for a principal (e.g. , ).
Policy or permit -- that policy permitted the effect before commit (e.g. , ).
Decision or compliance -- that a decision or compliance check occurred (e.g. , ).
Human authorization -- that a named, accountable human, or a quorum of distinct humans, approved the exact action (, ).
Transparency -- that a statement was registered in an append-only log ().

These are complementary layers, not competitors: a single high-risk action may warrant a delegation receipt AND a policy permit AND a human authorization. Yet each effort defines only its own native artifact and trust semantics. Without a composition profile, the relying party must correlate heterogeneous artifacts itself -- in particular, it must establish that the several artifacts concern the same material action rather than different ones spliced together (a cross-binding attack). The Entity Attestation Token provides a CBOR mechanism for composing claims from multiple attesting environments. EP-AEC applies a related verifier-dispatch pattern to JSON/JCS evidence while adding a relying-party requirement and an explicit same-action check. This is a scoped design comparison, not a claim that heterogeneous evidence composition is otherwise absent.

Scope and non-goals EP-AEC defines (1) a composition object that references component receipts and can record the presenter's descriptive requirement over them, and (2) an offline verification algorithm. EP-AEC does NOT define any component receipt format, does not require any particular component to be present, and does not bless any component specification. It is deliberately minimal: its central normative content is the same-action binding check and the relying-party requirement evaluation.

Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Action Object: the canonical representation of the external effect being authorized, as defined by Section 3.
Canonical action digest: the SHA-256 digest of the JCS serialization of the Action Object, expressed as lowercase hexadecimal, optionally prefixed "sha256:". The Action Object MUST conform to the I-JSON profile of Section 3 (strings, booleans, null, arrays, objects, and safe integers only) so that the digest is byte-identical across implementations.
Component: one referenced receipt within a chain, carrying a type, the receipt evidence, and an optional human-readable label.
Component verifier: a function that verifies one component and returns both a validity result AND the canonical action digest to which the integrity-protected native evidence is bound.
Requirement: a Boolean expression over component types that determines SATISFIED.

The Authorization Evidence Chain object ", "components": [ { "type": "ep-quorum", "label": "two-person human authorization", "evidence": { ... EP-QUORUM-v1 object ... } }, { "type": "policy-permit", "label": "machine policy permit", "evidence": { ... permit receipt ... } }, { "type": "delegation", "label": "agent delegation", "evidence": { ... delegation receipt ... } } ], "requirement": "ep-quorum AND policy-permit" } ]]>

"@version" (string, REQUIRED) -- MUST be "EP-AEC-v1".
"action" (object, REQUIRED) -- the Action Object to which every component must be bound.
"action_digest" (string, OPTIONAL) -- if present, MUST equal the canonical action digest recomputed from "action"; a mismatch is a fatal error.
"components" (array, REQUIRED, non-empty) -- each has "type" (string), "evidence" (object), and optional "label" (string). Labels are display metadata and MUST NOT satisfy a requirement identifier.
"requirement" (string, OPTIONAL) -- a Boolean expression (). NOTE (changed in -01): this member is PRESENTER-SUPPLIED -- a claim of what the chain satisfies, never the relying party's sufficiency bar; see . Its absence has no effect on SATISFIED when the verifier has an out-of-band relying-party requirement.

The chain carries the Action Object once; components reference the same action by digest rather than re-embedding it. This is what makes the same-action binding check possible and is the heart of the format.

Relying-party satisfaction inputs Internal agreement among presenter-supplied artifacts does not satisfy a relying party's evidence requirement. Before returning SATISFIED, the verifier MUST receive the following values from relying-party-controlled configuration:

the requirement expression;
the expected action digest computed from the action the executor is actually about to perform;
an explicit verification time; and
for each built-in human component, the acceptance profile described in .

If the expected action digest is absent, malformed, or differs from the canonical digest of C.action, the verifier MUST return UNSATISFIED. The expected digest MUST NOT be taken from C or any component in C.

Verification algorithm A verifier is configured with a set of component verifiers keyed by type. Given a chain C, the verifier MUST proceed fail-closed:

If C is malformed (missing "@version", wrong version, missing or non-object "action", or empty "components"), or exceeds the implementation's documented depth, node, component, expression, or string-byte limits, return UNSATISFIED.
Compute chain_digest = canonical action digest of C.action. If C.action_digest is present and does not equal chain_digest, return UNSATISFIED.
Compare chain_digest to the expected action digest supplied by the relying party. If the expected digest is absent or differs, return UNSATISFIED.
For each component k:
1. If no verifier is registered for k.type, mark k unsatisfied (reason: no verifier) and continue.
2. Invoke the verifier on k.evidence. It returns valid and action_digest. Any exception marks k unsatisfied.
3. k is eligible iff valid is true AND the returned action_digest equals chain_digest. A valid component that binds a different action MUST be treated as unsatisfied (reason: binds a different action). This is the cross-binding defense.
4. If eligible, add k.type to the satisfied set. k.label MUST NOT be added; it is presenter-controlled display metadata.
Evaluate only the requirement supplied by the relying party over the satisfied set (). If no relying-party requirement was supplied, return UNSATISFIED. C.requirement MAY be evaluated for descriptive reporting but MUST NOT produce SATISFIED. Record requirement_source accordingly.
Return SATISFIED iff the relying-party requirement evaluates true and every acceptance input in passed; otherwise return UNSATISFIED.
Any unexpected error at any step MUST yield UNSATISFIED.

The result MUST carry a Boolean "satisfied" member and SHOULD include, per component, whether it verified and whether it was bound, with a reason for any failure. Existing implementations may retain an "allow" compatibility alias, but specifications and new callers MUST interpret it only as evidence satisfaction, not local authorization.

Material-Action Matching EP-AEC-v1 carries one JCS action object and uses its canonical digest as the chain join key. A component whose native format uses a different action representation is eligible only when its native verifier or a separate adapter has established, under an exact relying-party-pinned mapping profile, that the integrity-protected native payload maps to the chain action. A presenter-supplied label, digest, or mapping profile is insufficient. The candidate Canonical Action IDentifier specification defines a typed action object and the closed mapping verdicts EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, and INDETERMINATE. An AEC adapter may use that algorithm, but MUST treat NOT_EQUIVALENT and INDETERMINATE as unbound. AEC itself does not infer semantic equivalence and does not replace the native verifier.

Requirement expressions A requirement is a Boolean expression with the grammar: IDENT matches a component type in the satisfied set; an unknown identifier evaluates to false. Implementations MUST evaluate the expression with a bounded parser and MUST NOT use a general-purpose evaluator. AND and OR have EQUAL binding strength and are evaluated strictly left to right; implementations MUST NOT assume AND binds tighter than OR. Parentheses group explicitly and are the only precedence mechanism. Example: "ep-quorum AND (policy-permit OR delegation)" requires a human quorum plus either a policy permit or a delegation receipt, all bound to the same action.

Whose requirement is it? (changed in -01) The chain document's "requirement" member is supplied by the PRESENTER of the chain. A presenter must never be able to choose its own sufficiency bar: a chain that says "delegation" satisfies itself, however weak, if the verifier takes the document's word for what suffices. This is the same confused-deputy class as a quorum policy read from the object it governs. Accordingly: a verifier MUST accept a requirement expression supplied out-of-band by the RELYING PARTY. The document's member is treated as a recorded claim only and MUST NOT produce SATISFIED. The result MUST record which source was evaluated (requirement_source: "relying_party" or "presenter"), and SHOULD note when a presenter requirement was ignored in favor of a pinned one. The document member is OPTIONAL descriptive metadata; omission MUST NOT weaken, replace, or prevent evaluation of the out-of-band relying-party requirement. If no relying-party requirement is supplied, the verifier MUST return UNSATISFIED whether or not the document member is present. The reference implementations (JavaScript, Python, Go) implement this behavior and agree on shared conformance vectors covering both sources, including reject_presenter_weak_bar_rp_bar_unsatisfied in the EP-AEC-ROLE-v1 suite, where the presenter's weak bar would pass and the relying party's pinned bar correctly fails. The generalization of this principle -- the entire sufficiency policy (requirement, freshness, revocation, required bindings) supplied by the relying party, with a purpose-relative classified verdict -- is specified in .

The human-authorization leg Human-authorization artifacts now exist in more than one ecosystem. A relying party that needs the EMILIA receipt or quorum guarantee can require the typed "ep-receipt" or "ep-quorum" leg explicitly while composing it with identity, delegation, permit, or other approval evidence. AEC does not infer that a generic policy decision or operator signature represents a named human ceremony. The built-in "ep-quorum" and "ep-receipt" verifiers are defined by and ; all other component types and their trust inputs are supplied by the relying party. A generic operator signature is not a human ceremony. The "ep-receipt" built-in MUST accept only the Trust Receipt of Section 6.2 under a relying-party profile that pins the approver directory, Class-A key class, expected WebAuthn RP ID, an exact allowlist of accepted signed WebAuthn client-data origins, policy hash, log key, maximum evidence age, verification time, and a fresh registry snapshot. Every counted signoff MUST carry WebAuthn user presence and user verification and bind the pinned approver identity. A bare Ed25519 operator envelope MUST be unsatisfied for this type. The "ep-quorum" built-in MUST compare the presented quorum policy byte-for-byte to the relying-party-pinned policy and MUST pin the RP ID, an exact allowlist of accepted signed WebAuthn client-data origins, signed context policy, maximum evidence age, and each key-to-approver-to-role mapping. A safety-critical quorum profile MUST require at least two distinct humans. Ordered mode MUST require the signed predecessor chain defined by . An internally valid quorum under presenter-supplied keys or a weaker presenter-supplied policy is unsatisfied. For both built-ins, the relying-party directory snapshot MUST have an authenticated checked-at instant and maximum staleness. A key that is inactive, outside its validity window, revoked at the verification time, or absent from that fresh snapshot MUST be unsatisfied.

The bounded-capability operation leg A static bounded-capability receipt authorizes capability issuance and MUST NOT be treated as bound to every later exercise. It is therefore not an eligible component of an exercise chain merely because the proposed action falls within its scope. A bounded-capability-operation component is eligible only when its integrity-protected operation record binds the chain's exact action digest and its native verifier verifies the referenced capability receipt, issuance authorization, scope result, and operation record. AEC does not query or reserve current budget. A capability component MUST NOT satisfy ep-receipt, ep-quorum, or any human-authorization role.

Security Considerations Presenter-chosen sufficiency (fixed in -01). Prior to this revision the requirement was read only from the presented document, letting a presenter select the bar its own evidence would be judged against. Section "" closes this: relying-party-supplied requirements take precedence and the evaluated source is recorded. Deployments of -00 verifiers SHOULD upgrade or wrap verification with an out-of-band requirement check. Presenter-chosen action. Component agreement proves only that the components agree with each other. Without an executor-owned expected action, a presenter can construct a perfectly consistent chain for a different action. The relying party MUST compute the expected digest from the action at its own enforcement point and verification MUST fail closed when that input is absent. Cross-binding (action substitution). The core threat is splicing artifacts bound to different actions into one chain. Step 3c of defeats this by requiring every satisfied component to return the chain's exact canonical digest from integrity-protected native evidence. The strength of this defense rests entirely on the canonical digest being byte-identical across implementations; the I-JSON profile ( Section 3) is therefore normative, and one restriction in it is load-bearing enough to restate here: canonical payloads MUST NOT contain non-integer numbers (amounts travel as strings). Within that restriction the reference canonicalizers coincide with RFC 8785 output; full RFC 8785 number serialization (for payloads outside the profile) is an open conformance item, and implementations MUST reject payloads containing non-integer numbers rather than guess. Component verifier trust. A chain is only as sound as its weakest registered verifier and the keys it trusts. Relying parties MUST configure verifiers and trust anchors explicitly; an unconfigured type is unsatisfied, never assumed. Implementations MUST NOT allow application-supplied verifiers to replace the reserved "ep-receipt" or "ep-quorum" built-ins. An execution service MUST pin its custom verifier registry and verifier trust keys before it accepts a presented chain. It MUST NOT accept verifier code, trust keys, or human-acceptance profiles in the same transaction as presenter-controlled evidence; doing so lets the presenter define the proof that its own evidence must pass. Label and key-role confusion. Component labels are supplied by the presenter and MUST remain display-only. Human acceptance MUST be derived from the typed built-in verifier and its relying-party profile, not from a label, a key named inside the evidence, or a key trusted for another component type. WebAuthn origin confusion. Matching the authenticator-data RP ID hash is necessary but does not constrain the origin carried in the signed client data. A built-in human leg MUST decode the signed clientDataJSON, require a syntactically valid origin string, and compare it for exact membership in a non-empty relying-party allowlist. The allowlist MUST NOT be taken from the presented receipt or quorum. A missing or mismatched origin is unsatisfied. Requirement under-specification. A weak requirement yields a weak decision. Requirements SHOULD name every leg the relying party depends on, including the human leg where accountability is required. Freshness and revocation. EP-AEC composes point-in-time evidence; it does not by itself prove the absence of a later revocation. An SATISFIED decision using either built-in human leg MUST use an explicit verification time, a relying-party maximum age, and a fresh authenticated registry snapshot. Offline historical verification without those inputs MAY report cryptographic validity but MUST NOT return SATISFIED. One-time execution is stateful. An offline SATISFIED says that the evidence satisfied the relying party's inputs at a stated instant; it cannot prove that another executor has not already acted on the same authorization. A consequential executor MUST place a shared, atomic consumption store in the execution path, reserve the stable executor-computed action digest before the effect, and commit or conservatively freeze that reservation after the effect begins. The canonical action MUST therefore include a unique action-instance identifier or nonce whenever two otherwise identical effects may be independently authorized. Consumption MUST NOT be keyed by a presenter-selected component identifier: an invalid decoy component or an alternate valid proof could otherwise create a fresh replay key. A storage outage, ambiguous commit, or unavailable durable decision log MUST refuse or freeze execution; it MUST NOT fall back to an in-memory or stateless path. A committed consumption key MUST NOT expire while the action could be presented again. A production decision log MUST continue one atomically advanced shared head across replicas and restarts; a process-local hash chain streamed to a sink does not satisfy this requirement because it can fork or restart from genesis. A successful append response MUST be followed by immediate readback of the exact submitted sequence, predecessor, record identifier, and canonical content. The execution service MUST independently recompute the returned record hash and compare its non-chain fields exactly to the requested decision before acting. A backend that reports success without making the record observable creates an indeterminate outcome and execution MUST remain refused or frozen. Execution binding has a host-language boundary. An executor SHOULD clone and make immutable the expected Action Object before the first asynchronous storage or logging operation, and SHOULD pass only that snapshot to the effect adapter. This closes mutation-after-verification races inside the enforcement process. The effect adapter and every path to the physical or external effect remain part of the trusted computing base; EP-AEC cannot stop a privileged adapter from executing a different operation outside the gate. No transport assumptions. EP-AEC is a data structure; it inherits the confidentiality and integrity properties of whatever conveys it. It is fail-closed by construction ().

Relationship to Other Work EP-AEC is complementary to, and composes, the efforts in . It is the JSON/JCS analogue of the EAT detached-bundle composition model and can itself be registered as a SCITT signed statement for transparency. It neither extends nor constrains , , , or ; each plugs in as a component type. A Bounded Capability Receipt () can be recursively verified by a native bounded-capability-operation component. The static grant itself is not treated as bound to every exercise. EP-AEC does not query remaining budget, reserve funds, or promote SATISFIED to spend authority; those mutable state transitions remain at the enforcement point.

IANA Considerations This document has no IANA actions. A future revision may request a media type (e.g. "application/ep-aec+json") and a registry of component type identifiers should the work be adopted.

Changes in -03

Made the relying-party requirement and executor-computed expected action mandatory acceptance inputs.
Made presenter labels display-only and reserved the built-in human component verifiers against application override; stateful execution pins custom verifier and key registries before transaction input.
Profiled the human legs as a fresh Class-A Trust Receipt or an exact distinct-human quorum under relying-party-pinned policy, audience, signed WebAuthn origin allowlist, identity-role directory, and active registry snapshot.
Renamed the chain verdict from ALLOW/DENY to SATISFIED/UNSATISFIED and retained "allow" only as a compatibility alias in the reference APIs.
Added profile-bounded material-action matching and removed effect and ceremony record definitions that belong in their own component specifications.
Added bounded parsing, canonical-JSON resource limits, and fail-closed host-language exception handling requirements.
Specified action-digest-keyed one-time execution, non-expiring committed keys, conservative indeterminate outcomes, immutable action snapshots, and atomic shared-head decision logging across replicas and restarts with exact successful-append readback and independently checked logger acknowledgments.
Clarified the bounded-capability composition boundary: receipt and operation evidence can satisfy slots, while live budget reservation remains an executor-side state transition.

Implementation Status A reference verifier and a runnable demonstration (composing a real EP human quorum with a policy-permit leg, and rejecting both a cross-binding attack and a missing human leg; examples/authorization-chain.mjs in the repository) are maintained as open-source software and are exercised offline, with no network dependency, by the reference suite's three language implementations (JavaScript, Python, Go), which agree on a shared conformance vector set. These are one project's implementations -- a cross-language consistency check, not independently developed implementations; a third party has separately executed and verified the published artifacts against a pinned commit, as reported to the IETF SECDISPATCH mailing list on 23 June 2026.