Network Working Group I. Schrock Internet-Draft EMILIA Protocol, Inc. Intended status: Informational 6 July 2026 Expires: 7 January 2027 Authorization Evidence Chains: Composing Heterogeneous Agent- Authorization Receipts (EP-AEC) draft-schrock-ep-authorization-evidence-chain-02 Abstract A growing family of Internet-Drafts defines signed "receipts" about an AI agent's action: delegation receipts that attest an agent was authorized to act for a principal, policy or permit receipts that attest a policy allowed an external effect, decision and compliance receipts, route authorizations, and human-authorization receipts that attest a named, accountable human approved a specific action. The mature efforts independently converged on a common substrate: bind the action with a canonical digest (JSON Canonicalization Scheme, RFC 8785) and sign it. No specification, however, defines how a relying party verifies that, for one action, the several heterogeneous receipts it has been handed all bind the same canonical action and each verify under their own rules, yielding a single, offline, fail- closed ALLOW or DENY. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and an offline verification algorithm that references existing receipts, checks that every component binds one canonical action digest, dispatches each component to a verifier for its type, and evaluates a fail-closed requirement expression. EP-AEC introduces no new receipt type and replaces none; it is the verifier-side glue that lets independently specified receipts compose into one accountability decision. This revision additionally profiles two optional component record types for that composition: the effect attestation, a post- execution record in which the executor signs the receipt identifier together with a digest of the observed effect, and ceremony evidence, a signed record of signing-ceremony telemetry (the challenge issued, viewed, and approved instants and the approver identity) that enables review-latency policies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Schrock Expires 7 January 2027 [Page 1] Internet-Draft Authorization Evidence Chains July 2026 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 7 January 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and non-goals . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Authorization Evidence Chain object . . . . . . . . . . . 4 4. Verification algorithm . . . . . . . . . . . . . . . . . . . 5 5. Requirement expressions . . . . . . . . . . . . . . . . . . . 7 6. Whose requirement is it? (changed in -01) . . . . . . . . . . 7 7. The human-authorization leg . . . . . . . . . . . . . . . . . 8 8. Effect Attestation . . . . . . . . . . . . . . . . . . . . . 8 9. Ceremony Evidence . . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Relationship to Other Work . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 14. Normative References . . . . . . . . . . . . . . . . . . . . 12 15. Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Schrock Expires 7 January 2027 [Page 2] Internet-Draft Authorization Evidence Chains July 2026 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. * 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 receipt. The relying party is left to correlate heterogeneous artifacts by hand, and in practice implementers hand-roll ad-hoc "composite proofs" with no shared correctness model -- in particular, no guarantee that the several receipts authorize the same action rather than different ones spliced together (a cross-binding attack). The Entity Attestation Token [RFC9711] provides a CBOR mechanism (detached submodules / detached EAT bundles) for composing claims from multiple attesting environments into one token. No equivalent exists for the predominantly JSON/JCS receipt cluster described above. This document fills that gap. Schrock Expires 7 January 2027 [Page 3] Internet-Draft Authorization Evidence Chains July 2026 1.1. Scope and non-goals EP-AEC defines (1) a composition object that references component receipts and declares a 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 only novel normative content is the same-action binding check and the requirement evaluation. 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 that component attests it authorized. Requirement a Boolean expression over component types/labels that determines ALLOW. 3. The Authorization Evidence Chain object Schrock Expires 7 January 2027 [Page 4] Internet-Draft Authorization Evidence Chains July 2026 { "@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" } * "@version" (string, REQUIRED) -- MUST be "EP-AEC-v1". * "action" (object, REQUIRED) -- the Action Object every component must authorize. * "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). * "requirement" (string, REQUIRED) -- a Boolean expression (Section 5). 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 6. 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. 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", empty "components", or missing "requirement"), return DENY. Schrock Expires 7 January 2027 [Page 5] Internet-Draft Authorization Evidence Chains July 2026 2. Compute chain_digest = canonical action digest of C.action. If C.action_digest is present and does not equal chain_digest, return DENY. 3. 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 SATISFIED 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 satisfied, add k.type and k.label (if present) to the satisfied set. 4. Select the requirement to evaluate: if the relying party supplied its own requirement expression to the verifier, use it and record requirement_source = "relying_party"; otherwise use C.requirement and record requirement_source = "presenter" (Section 6). Evaluate it over the satisfied set (Section 5). Return ALLOW iff it evaluates true; otherwise DENY. 5. Any unexpected error at any step MUST yield DENY. The result SHOULD include, per component, whether it verified and whether it was bound, with a reason for any failure, to support audit. Two optional component record types, the effect attestation (Section 8) and ceremony evidence (Section 9), attach additional evidence rules on top of step 3. Findings from those rules are conflict-class: they never move the outcome toward ALLOW, and in the graded verdict set used by the reference evaluation (admissible, missing_evidence, stale, conflicted, unverifiable) they downgrade the verdict to "conflicted". A record whose signature does not verify is "unverifiable", which is strictly worse and is never softened to "conflicted". No rule in this document ever moves a verdict toward a more admissible one. Schrock Expires 7 January 2027 [Page 6] Internet-Draft Authorization Evidence Chains July 2026 5. Requirement expressions A requirement is a Boolean expression with the grammar: expr := term (('AND' | 'OR') term)* term := '(' expr ')' | IDENT IDENT matches a component type or label 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. 6. 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, and when one is supplied it MUST take precedence over the document's; the document's member is then treated as a recorded claim only. 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 remains REQUIRED for self-describing interchange, but relying parties SHOULD pin their own bar for any consequential decision. The reference implementations (JavaScript, Python, Go) implement this behavior and agree on shared conformance vectors covering both sources, including a vector 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]. Schrock Expires 7 January 2027 [Page 7] Internet-Draft Authorization Evidence Chains July 2026 7. The human-authorization leg Of the receipt families enumerated in Section 1, only the EP human- authorization receipt binds a named, accountable human (or, via [EP-QUORUM], a quorum of distinct humans under separation of duties) to the exact action. Several policy/permit formats reserve a slot for a threshold or multi-party signature but specify no human semantics behind it. EP-AEC lets a relying party require the human leg explicitly (e.g. requirement includes "ep-quorum") while composing it with machine-side delegation and permit receipts. The built-in component verifiers "ep-quorum" and "ep-receipt" are defined by [EP-QUORUM] and [EP-RECEIPTS] respectively; all other types are supplied by the relying party. 8. Effect Attestation Every receipt family enumerated in Section 1 attests something about an action before or at authorization time. None of them states what was then done. An effect attestation is a post-execution evidence record that closes that "approved X, executed Y" gap: the executor signs the receipt identifier of the authorization it acted under together with a digest of the effect it observed. Any third party holding both the authorization (which commits to the approved effect) and the effect attestation can check divergence offline: if the observed effect digest differs from the approved action's committed effect digest, "approved X, executed Y" is demonstrated by the two records alone, with no access to the executing system, and in the evidence verdict the divergence surfaces as a conflict. Use of this record type is OPTIONAL. Its component type identifier is "effect_attestation". When it is used, the following rules apply: * The record MUST carry the receipt identifier of the authorization it attests and the digest of the observed effect, and MUST be signed by the executor. The component verifier for this type returns, alongside "valid" and "action_digest", the fields "receipt_id", "observed_effect_digest", and, where the verifier could read the approved effect out of the referenced authorization, "committed_effect_digest". Digest values are compared as lowercase hexadecimal after removal of an optional "sha256:" prefix. * An effect attestation whose executor signature does not verify, or whose executor key is not pinned by the relying party, is inadmissible as evidence: the component verifier MUST report it invalid, and it MUST NOT be weighed as effect evidence at all (fail closed). Schrock Expires 7 January 2027 [Page 8] Internet-Draft Authorization Evidence Chains July 2026 * The committed effect digest against which the observed digest is compared MUST NOT be taken from the presenter. It is either pinned by the relying party (the "expected_effect_digest" member of the relying-party policy) or read by the component verifier from the referenced authorization; where both are available, the relying-party pin takes precedence. * If the observed effect digest differs from the committed effect digest, the verification result MUST record the reason code "effect_divergence" and treat the finding as a conflict (Section 4); it never moves the outcome toward ALLOW. * A verified effect attestation that carries no observed effect digest MUST likewise be recorded under "effect_divergence" and treated as a conflict (fail closed). * A verified effect attestation with no committed effect digest to compare against MUST record the reason code "effect_commitment_missing" and be treated as a conflict, never as admissible: an observed effect that cannot be tied to an approved effect does not show the effect was approved (fail closed). Stated honestly: an effect attestation says what the executor CLAIMS was observed. It is one more accountable, signed leg in the chain, not ground truth. Its value is that an executor that misreports the effect is now misreporting in a signed, attributable artifact bound to a specific receipt, and that a divergence between two honest records is checkable offline by any third party holding both. How the observed effect is represented and digested is action-family specific and out of scope for this document. 9. Ceremony Evidence A human-authorization receipt proves that an accountable human approved the exact action. It does not show how the approval happened. Ceremony evidence carries signing-ceremony telemetry as a first-class evidence record: the instants at which the authorization challenge was issued, viewed, and approved, and the approver identity. Its component type identifier is "ceremony_evidence"; the component verifier for this type returns, alongside "valid" and "action_digest", the fields "approver", "issued_at", "viewed_at", and "approved_at". The component verifier proves the ceremony record is authentic; the rules below judge what it says. Ceremony evidence enables review-latency policies. An approval that comes in below a policy floor every time is itself evidence of rubber-stamping: the recorded human review contradicts a genuine one, and a relying party MAY weigh it as a conflict. A relying party Schrock Expires 7 January 2027 [Page 9] Internet-Draft Authorization Evidence Chains July 2026 adopting such a policy sets a review-latency floor (the "ceremony_min_review_sec" member of the relying-party policy). When a floor is set, the following rules apply: * The review interval of a verified ceremony record is "approved_at" minus "viewed_at", in whole seconds. * A verified ceremony record whose review interval is strictly below the floor MUST be recorded under the reason code "rubber_stamped_ceremony" and treated as a conflict (Section 4); it never moves the outcome toward ALLOW. * If the telemetry on a verified ceremony record is absent or unusable (a missing or unparseable "viewed_at" or "approved_at", or "approved_at" earlier than "viewed_at"), real review cannot be shown; the record MUST be recorded under the reason code "ceremony_telemetry_missing" and treated as a conflict, never as a silent pass (fail closed). * A ceremony record whose signature does not verify is unverifiable; it is never softened to a conflict. When no floor is set, this document attaches no judgment to the telemetry. Stated honestly: ceremony telemetry is operator- originated. The issued, viewed, and approved instants are recorded by the operator of the signing ceremony, not by an independent observer; ceremony evidence gives the relying party an accountable, signed record of the claimed timeline, not an independent measurement of human attention. 10. 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 "Whose requirement is it? (changed in -01)" 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. Cross-binding (action substitution). The core threat is splicing receipts that authorize different actions into one chain. Step 3c of Section 4 defeats this by requiring every satisfied component to attest the chain's exact canonical digest. 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- Schrock Expires 7 January 2027 [Page 10] Internet-Draft Authorization Evidence Chains July 2026 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. 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. Components that carry status/freshness evidence SHOULD be verified against the relying party's freshness policy. 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 4). Post-execution and ceremony evidence are operator-originated. The effect attestation (Section 8) and ceremony evidence (Section 9) records carry what the executor and the ceremony operator report, signed and attributable, not an independent measurement. Their guarantee is accountability, not ground truth: a false report is a signed, bound artifact, and a divergence or below-floor review is checkable offline. Both are fail-closed in the same direction as the rest of this document: a signature that does not verify is unverifiable, a missing committed effect or missing ceremony telemetry is a conflict, and no finding from either record ever moves a verdict toward a more admissible one (Section 4). 11. 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. Schrock Expires 7 January 2027 [Page 11] Internet-Draft Authorization Evidence Chains July 2026 12. 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. 13. 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. The evidence rules for the effect-attestation and ceremony-evidence record types (Section 8, Section 9) are implemented in a JavaScript- only reference evaluation in the same repository; they are not yet part of the shared cross-language conformance vector set. 14. 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, June 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 7 January 2027 [Page 12] 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, . 15. 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, . [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- Schrock Expires 7 January 2027 [Page 13] Internet-Draft Authorization Evidence Chains July 2026 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 7 January 2027 [Page 14]