Network Working Group I. Schrock Internet-Draft EMILIA Protocol, Inc. Intended status: Informational 19 July 2026 Expires: 20 January 2027 Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC) draft-schrock-ep-authorization-evidence-chain-03 Abstract Consequential agent actions can produce heterogeneous identity, delegation, policy, permit, approval, transparency, and execution artifacts. Each artifact can verify under its own specification while still referring to a different action or filling a different evidentiary role. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and an offline verification algorithm that verifies each component under relying-party-selected trust inputs, checks material-action binding, and evaluates a relying-party-pinned requirement. The result is SATISFIED or UNSATISFIED. It states whether the presented evidence filled the relying party's named evidence slots; it is not a universal authorization decision. An executor makes the separate local AUTHORIZED decision. AEC introduces no new component receipt type and does not replace any native verifier. Presenter labels, keys, requirements, and action identifiers cannot establish their own authority. 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 20 January 2027. Schrock Expires 20 January 2027 [Page 1] Internet-Draft Authorization Evidence Chains July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope and non-goals . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Authorization Evidence Chain object . . . . . . . . . . . 4 4. Relying-party satisfaction inputs . . . . . . . . . . . . . . 5 5. Verification algorithm . . . . . . . . . . . . . . . . . . . 6 6. Material-Action Matching . . . . . . . . . . . . . . . . . . 7 7. Requirement expressions . . . . . . . . . . . . . . . . . . . 7 8. Whose requirement is it? (changed in -01) . . . . . . . . . . 8 9. The human-authorization leg . . . . . . . . . . . . . . . . . 8 10. The bounded-capability operation leg . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Relationship to Other Work . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 14. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . . 12 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 16. Normative References . . . . . . . . . . . . . . . . . . . . 13 17. Informative References . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. 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. Schrock Expires 20 January 2027 [Page 2] Internet-Draft Authorization Evidence Chains July 2026 * Delegation -- that the agent was authorized to act for a principal (e.g. [DRP], [DAAP]). * Policy or permit -- that policy permitted the effect before commit (e.g. [PERMIT], [AGENTROA]). * Decision or compliance -- that a decision or compliance check occurred (e.g. [ACTA], [ASQAV]). * Human authorization -- that a named, accountable human, or a quorum of distinct humans, approved the exact action ([EP-RECEIPTS], [EP-QUORUM]). * Transparency -- that a statement was registered in an append-only log ([SCITT]). 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 [RFC9711] 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. 1.1. 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. Schrock Expires 20 January 2027 [Page 3] Internet-Draft Authorization Evidence Chains July 2026 2. Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" 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. Action Object the canonical representation of the external effect being authorized, as defined by [EP-RECEIPTS] Section 3. Canonical action digest the SHA-256 digest of the JCS [RFC8785] serialization of the Action Object, expressed as lowercase hexadecimal, optionally prefixed "sha256:". The Action Object MUST conform to the I-JSON [RFC7493] profile of [EP-RECEIPTS] 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. 3. The Authorization Evidence Chain object { "@version": "EP-AEC-v1", "action": { ... Action Object ... }, "action_digest": "sha256:", "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" } Schrock Expires 20 January 2027 [Page 4] Internet-Draft Authorization Evidence Chains July 2026 * "@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 (Section 7). NOTE (changed in -01): this member is PRESENTER- SUPPLIED -- a claim of what the chain satisfies, never the relying party's sufficiency bar; see Section 8. 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. 4. 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 Section 9. 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. Schrock Expires 20 January 2027 [Page 5] Internet-Draft Authorization Evidence Chains July 2026 5. 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: 1. 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. 2. Compute chain_digest = canonical action digest of C.action. If C.action_digest is present and does not equal chain_digest, return UNSATISFIED. 3. Compare chain_digest to the expected action digest supplied by the relying party. If the expected digest is absent or differs, return UNSATISFIED. 4. 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. 5. Evaluate only the requirement supplied by the relying party over the satisfied set (Section 7). 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. 6. Return SATISFIED iff the relying-party requirement evaluates true and every acceptance input in Section 4 passed; otherwise return UNSATISFIED. 7. Any unexpected error at any step MUST yield UNSATISFIED. Schrock Expires 20 January 2027 [Page 6] Internet-Draft Authorization Evidence Chains July 2026 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. 6. 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. 7. Requirement expressions A requirement is a Boolean expression with the grammar: expr = term *(WS operator WS term) term = ident / "(" WS expr WS ")" operator = "AND" / "OR" / "&&" / "||" ident = 1*(ALPHA / DIGIT / "." / ":" / "-" / "_") WS = *(SP / HTAB / CR / LF) 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. Schrock Expires 20 January 2027 [Page 7] Internet-Draft Authorization Evidence Chains July 2026 8. 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 [I-D.schrock-ep-action-evidence-graph]. 9. 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 [EP-QUORUM] and [EP-RECEIPTS]; 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 [EP-RECEIPTS] 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 Schrock Expires 20 January 2027 [Page 8] Internet-Draft Authorization Evidence Chains July 2026 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 [EP-QUORUM]. 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. 10. 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. 11. 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 "Section 8" 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 Schrock Expires 20 January 2027 [Page 9] Internet-Draft Authorization Evidence Chains July 2026 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 Section 5 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 ([EP-RECEIPTS] 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. Schrock Expires 20 January 2027 [Page 10] Internet-Draft Authorization Evidence Chains July 2026 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 (Section 5). Schrock Expires 20 January 2027 [Page 11] Internet-Draft Authorization Evidence Chains July 2026 12. Relationship to Other Work EP-AEC is complementary to, and composes, the efforts in Section 1. It is the JSON/JCS analogue of the EAT [RFC9711] detached-bundle composition model and can itself be registered as a SCITT [SCITT] signed statement for transparency. It neither extends nor constrains [DRP], [PERMIT], [ACTA], or [AGENTROA]; each plugs in as a component type. A Bounded Capability Receipt ([EP-BOUNDED-CAP]) 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. 13. 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. 14. 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. Schrock Expires 20 January 2027 [Page 12] Internet-Draft Authorization Evidence Chains July 2026 * 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. 15. 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. 16. Normative References [EP-QUORUM] Schrock, I., "Multi-Party Quorum Authorization for High- Risk Agent Actions (EP-QUORUM)", Work in Progress, Internet-Draft, draft-schrock-ep-quorum, June 2026, . [EP-RECEIPTS] Schrock, I., "Authorization Receipts for High-Risk Agent Actions (EP)", Work in Progress, Internet-Draft, draft- schrock-ep-authorization-receipts-07, July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Schrock Expires 20 January 2027 [Page 13] Internet-Draft Authorization Evidence Chains July 2026 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [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, . 17. Informative References [ACTA] Farley, A., "Signed Decision Receipts for Machine-to- Machine Access Control", Work in Progress, Internet-Draft, draft-farley-acta-signed-receipts, 2026, . [AGENTROA] Nivalto, "Agent Route Origin Authorization (AgentROA)", Work in Progress, Internet-Draft, draft-nivalto-agentroa- route-authorization, 2026, . [ASQAV] Marques, J., "Compliance Profile of Signed Action Receipts for AI Agents", Work in Progress, Internet-Draft, draft- marques-asqav-compliance-receipts, 2026, . [DAAP] Mishra, "Delegated Agent Authorization Protocol (DAAP)", Work in Progress, Internet-Draft, draft-mishra-oauth- agent-grants, 2026, . [DRP] Nelson, R., "Delegation Receipt Protocol for AI Agent Authorization", Work in Progress, Internet-Draft, draft- nelson-agent-delegation-receipts, 2026, . Schrock Expires 20 January 2027 [Page 14] Internet-Draft Authorization Evidence Chains July 2026 [EP-BOUNDED-CAP] Schrock, I., "Bounded Capability Receipts and Durable Spend Control for Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-bounded-capability- receipts-00, July 2026, . [I-D.schrock-ep-action-evidence-graph] Schrock, I., "Action Evidence Graphs and Evidence Policy Replay for High-Risk Agent Actions (EP-AEG)", Work in Progress, Internet-Draft, draft-schrock-ep-action- evidence-graph-00, July 2026, . [PERMIT] Lee, Y., "Permit Receipts for Permit-Before-Commit Authorization of AI-Agent and Workload External Effects", Work in Progress, Internet-Draft, draft-lee-orprg-permit- receipts, 2026, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [SCITT] IETF SCITT WG, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2026, . Author's Address Iman Schrock EMILIA Protocol, Inc. United States of America Email: team@emiliaprotocol.ai Schrock Expires 20 January 2027 [Page 15]