Authorization Evidence Chains: Composing Heterogeneous Agent-Authorization Receipts (EP-AEC)
draft-schrock-ep-authorization-evidence-chain-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Iman Schrock | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schrock-ep-authorization-evidence-chain-00
Network Working Group I. Schrock
Internet-Draft EMILIA Protocol, Inc.
Intended status: Informational 22 June 2026
Expires: 24 December 2026
Authorization Evidence Chains: Composing Heterogeneous Agent-
Authorization Receipts (EP-AEC)
draft-schrock-ep-authorization-evidence-chain-00
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.
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."
Schrock Expires 24 December 2026 [Page 1]
Internet-Draft Authorization Evidence Chains June 2026
This Internet-Draft will expire on 24 December 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Authorization Evidence Chain object . . . . . . . . . . . 4
4. Verification algorithm . . . . . . . . . . . . . . . . . . . 5
5. Requirement expressions . . . . . . . . . . . . . . . . . . . 6
6. The human-authorization leg . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Relationship to Other Work . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
12. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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]).
Schrock Expires 24 December 2026 [Page 2]
Internet-Draft Authorization Evidence Chains June 2026
* 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.
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.
Schrock Expires 24 December 2026 [Page 3]
Internet-Draft Authorization Evidence Chains June 2026
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
{
"@version": "EP-AEC-v1",
"action": { ... Action Object ... },
"action_digest": "sha256:<hex>",
"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.
Schrock Expires 24 December 2026 [Page 4]
Internet-Draft Authorization Evidence Chains June 2026
* "components" (array, REQUIRED, non-empty) -- each has "type"
(string), "evidence" (object), and optional "label" (string).
* "requirement" (string, REQUIRED) -- a Boolean expression
(Section 5).
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.
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. Evaluate C.requirement over the satisfied set (Section 5).
Return ALLOW iff it evaluates true; otherwise DENY.
5. Any unexpected error at any step MUST yield DENY.
Schrock Expires 24 December 2026 [Page 5]
Internet-Draft Authorization Evidence Chains June 2026
The result SHOULD include, per component, whether it verified and
whether it was bound, with a reason for any failure, to support
audit.
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. Operator precedence is left-associative;
parentheses group explicitly. 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. 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.
7. Security Considerations
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.
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.
Schrock Expires 24 December 2026 [Page 6]
Internet-Draft Authorization Evidence Chains June 2026
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).
8. 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.
9. 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.
10. 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) are maintained as open-source
software and are exercised offline, with no network dependency, by
three independent implementations (JavaScript, Python, Go) that agree
on a shared conformance vector set.
11. 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,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
quorum/>.
Schrock Expires 24 December 2026 [Page 7]
Internet-Draft Authorization Evidence Chains 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,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
authorization-receipts/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
12. 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,
<https://datatracker.ietf.org/doc/draft-farley-acta-
signed-receipts/>.
[AGENTROA] Nivalto, "Agent Route Origin Authorization (AgentROA)",
Work in Progress, Internet-Draft, draft-nivalto-agentroa-
route-authorization, 2026,
<https://datatracker.ietf.org/doc/draft-nivalto-agentroa-
route-authorization/>.
[ASQAV] Marques, J., "Compliance Profile of Signed Action Receipts
for AI Agents", Work in Progress, Internet-Draft, draft-
marques-asqav-compliance-receipts, 2026,
<https://datatracker.ietf.org/doc/draft-marques-asqav-
compliance-receipts/>.
Schrock Expires 24 December 2026 [Page 8]
Internet-Draft Authorization Evidence Chains June 2026
[DAAP] Mishra, "Delegated Agent Authorization Protocol (DAAP)",
Work in Progress, Internet-Draft, draft-mishra-oauth-
agent-grants, 2026, <https://datatracker.ietf.org/doc/
draft-mishra-oauth-agent-grants/>.
[DRP] Nelson, R., "Delegation Receipt Protocol for AI Agent
Authorization", Work in Progress, Internet-Draft, draft-
nelson-agent-delegation-receipts, 2026,
<https://datatracker.ietf.org/doc/draft-nelson-agent-
delegation-receipts/>.
[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, <https://datatracker.ietf.org/doc/draft-
lee-orprg-permit-receipts/>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[SCITT] IETF SCITT WG, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture, 2026,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>.
Author's Address
Iman Schrock
EMILIA Protocol, Inc.
United States of America
Email: team@emiliaprotocol.ai
Schrock Expires 24 December 2026 [Page 9]