| Internet-Draft | EP Architecture | June 2026 |
| Schrock | Expires 30 December 2026 | [Page] |
Autonomous and agentic systems now take consequential, often irreversible actions -- moving money, changing records, routing benefits, releasing effects -- at machine speed, while the evidence systems that establish accountability were built for the speed of humans taking those actions. Across regulation, audit, and insurance the same requirement recurs and the same artifact is missing: portable, offline-verifiable proof that a named, accountable human authorized a specific action before it executed, checkable by a third party without trusting the operator that produced it.¶
This document is the architectural overview of the EMILIA Protocol (EP): a human-authorization and oversight evidence layer for agentic and autonomous systems. It defines the layer's position relative to agent identity, delegation, policy, and transparency work; states the design invariants; and ties together the component specifications -- the authorization receipt, multi-party quorum, the enforcement point, the authorization evidence chain, long-term evidence-record renewal, authorization-posture advisories, and the human-oversight profile. EP composes with the other layers rather than replacing them; its contribution is the human- accountability apex and the composition seam that binds the layers' artifacts into one verifiable record.¶
EP proves authorization -- that a named human (or quorum) approved the exact action. It does not prove the action was understood, lawful, wise, or proportional. It is a necessary, not sufficient, condition for accountable autonomy, and this document is explicit about that boundary.¶
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 30 December 2026.¶
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.¶
Fifty years of access control answered "who is allowed in?" The dominant actors in software are no longer humans but agents that act on their behalf, and the unanswered question is no longer authentication but authorization at the moment of action: who approved that exact action, before it executed, and can anyone prove it later without trusting the system that produced the record?¶
Today that proof is an operator-controlled log: forgeable, backfillable, and unverifiable by an outside party. Every governing instrument -- the EU AI Act's logging and human-oversight articles, the NIST AI Risk Management Framework, US sectoral controls requiring authorization and separation of duties, cyber and crime insurance conditions precedent, and, for defense autonomy, DoD Directive 3000.09's "appropriate levels of human judgment" -- requires verifiable human authorization and specifies no format for it. EP supplies the format.¶
The architectural thesis is one sentence: no irreversible autonomous action without a verifiable human receipt.¶
EP is deliberately narrow in mechanism and broad in reach: it occupies the human-authorization layer and composes downward. Adjacent layers, and the relationship EP takes to each:¶
L4 to L7 binding. Because a human authorization is only as trustworthy as the upstream identity/delegation evidence it relied on, EP records that evidence inside the signed authorization context and can enforce its freshness fail-closed. This keeps EP agnostic to which identity or delegation standard prevails while making a stale or unconstrained upstream claim detectable after the fact.¶
EP is a small family of specifications around one primitive. Each makes
a distinct, independently verifiable claim; together they form the
human-authorization and oversight evidence layer. Component specifications
are published as separate EMILIA Protocol Internet-Drafts
(draft-schrock-ep-*).¶
A named human's device-bound signoff over one exact, canonicalized
action (JCS, [RFC8785]; Ed25519), producing a Trust
Receipt that a third party verifies fully offline. The apex of the
layer. Binding the signing key to a specific, named, accountable person
is achieved through device-bound user verification together with an
identity-binding profile (work in progress), so the authorizing party is
a person rather than an opaque key.
(draft-schrock-ep-authorization-receipts.)¶
M-of-N approval by distinct humans with ordering and separation of
duties -- the cryptographic form of the two-person rule, which a single
compromised or coerced approver cannot satisfy alone.
(draft-schrock-ep-quorum.)¶
The fail-closed gate: a high-risk action is refused (HTTP 428-style)
unless a valid, in-scope, unrevoked authorization receipt is present.
"No receipt, no execution," expressed as a manifest-driven policy
enforcement point. After a permitted action runs, the same point emits a
post-execution receipt bound to the authorization, so authorization and
execution form one verifiable chain.
(draft-schrock-ep-enforcement-point.)¶
A standard for binding the artifacts of the adjacent layers -- an
identity attestation, a delegation receipt, a policy decision, a
transparency inclusion proof, and the EP human authorization -- into a
single, order-preserving, verifiable evidence record. This is the
connective tissue that lets independently produced proofs be checked as
one chain.
(draft-schrock-ep-authorization-evidence-chain.)¶
An Evidence Record Syntax-style ([RFC4998]) renewal
chain so a receipt verifiable today remains verifiable after its original
algorithms weaken (for example sha256 to sha384), meeting the multi-year
retention schedules that regulation imposes on the records EP produces.
(draft-schrock-ep-evidence-record.)¶
Verifiable, scope-bound advisory signals (for example a risk or
posture indication) that inform a human approver or a policy decision.
By construction an advisory is never itself an authorization: it
MUST NOT be the sole gate on an action. This component is
Experimental. (draft-schrock-emilia-eye.)¶
An applicability profile for human-in-the-loop and human-on-the-loop
oversight of autonomous and cyber-physical systems, mapping the components
above to the human-oversight requirements of the NIST AI Risk Management
Framework and, for civilian high-risk systems, EU AI Act Article 14, with
DoD Directive 3000.09 as a further applicability. It introduces no new
cryptography; it applies the receipt primitive at authorization
boundaries. Primary applicability is civilian; defense (DoD 3000.09) and
the UN CCW debate are secondary.
(draft-schrock-ep-human-oversight-profile.)¶
An informational map of how the layers compose across efforts --
identity, delegation, policy, transparency, and the EP human-authorization
apex -- and the binding points between them.
(draft-schrock-ep-agent-trust-stack.)¶
An explicit algorithm registry and a hybrid (classical plus
post-quantum, for example Ed25519 with ML-DSA) signature mode, so
long-lived receipts stay verifiable across the post-quantum transition,
with a fail-closed verifier policy.
(draft-schrock-ep-pqc.)¶
Domain profiles that apply the receipt to a specific irreversible
action-type, registered in the EP profile registry. The first is grid
curtailment / Proof-of-Curtailment for verifiable demand response.
(draft-schrock-ep-grid-curtailment.)¶
Every component upholds the following, and any profile claiming EP conformance MUST preserve them:¶
The dominant risk is over-trust: treating the existence of a receipt as proof that an action was legitimate. A receipt proves authorization occurred at a stated scope, currency, and authority -- nothing more. Deployments and downstream representations MUST NOT overstate it.¶
EP proves a key signed; binding that key to the intended natural person is achieved through device-bound user verification and an identity-binding profile (work in progress), and is the explicit boundary of the architecture. Coercion of an authorized human, and a human authorizing an action they did not truly comprehend, are out of scope of the cryptographic guarantees; device-bound user verification and the display-fidelity requirements of the component specifications raise but do not eliminate these. Per-component security considerations are normative in each component document.¶
This document has no IANA actions.¶