COMPOSITION · OFFLINE VERIFICATION · IETF INTERNET-DRAFT

One verdict from many receipts.

An AI agent’s action leaves a trail of signed receipts — one says it was delegated, one says a policy permitted it, one says a named human approved it. They are written by different parties, in different formats, at different hops. Nothing defines how a relying party checks that they all describe the same action and each verify, then turns that into a single decision.

The Authorization Evidence Chain (EP-AEC) is that missing layer: a composition object and verifier that returns one offline, fail-closed ALLOW or DENY — with no network, no introspection endpoint, and no trust in the operator.

Read the Internet-Draft See the full spec

Run a receipt and verify it in 30 seconds, offline, no account: npx @emilia-protocol/crash-test

THE GAP

The field agreed on the receipt. Nobody agreed on the verdict.

A receipt per hop

A delegation receipt attests an agent was authorized to act for a principal. A policy or permit receipt attests a rule allowed the effect. A human-authorization receipt attests a named person approved it. Each is signed, each lives in its own format — and each only speaks for its own hop.

No one owns the verdict

The mature efforts independently converged on one substrate: bind the action with a canonical digest (JCS, RFC 8785) and sign it. But no specification defines how a relying party checks that the several receipts it was handed all bind the same action and each verify — and turns that into one decision.

Trust leaks in the gaps

Without a composite check, a verifier either trusts an operator to have stapled the right receipts together, or accepts a receipt that was issued for a different action. The join between “what was authorized” and “what actually happened” is exactly where audit breaks down.

WHAT EP-AEC DOES

A composition object, and a verifier for it.

EP-AEC takes the heterogeneous receipts handed to a relying party for one action and binds them to a single canonical action digest. Each receipt is checked under its own rules by a pluggable verifier; the chain then enforces an explicit requirement — which receipt types must be present — and yields one offline decision. It supplies the one leg the rest of the cluster does not: a named, accountable human’s authorization, composed alongside the machine-side delegation and policy receipts.

01 · Canonical action

Compute one canonical digest of the exact action (JCS / RFC 8785 + SHA-256). This is the single thing every receipt must point at.

02 · Collect receipts

Gather the heterogeneous receipts for that action — delegation, policy/permit, decision, and EP’s named-human authorization — regardless of which format or hop produced them.

03 · Cross-binding check

Verify every receipt binds the same canonical action. A receipt issued for a different action — replayed or swapped in — fails the chain by construction.

04 · Per-receipt verify

Each receipt is verified under its own rules by a pluggable verifier. AEC composes them; it does not replace or reinterpret any one format’s signature checks.

05 · Requirement policy

Apply the relying party’s requirement — e.g. “delegation AND policy AND a named human” — as an explicit, inspectable rule over receipt types.

06 · One verdict

Return a single, offline, fail-closed ALLOW or DENY. No network, no introspection endpoint, no trust in the operator. Anything missing or unverifiable means DENY.

WHY IT MATTERS

EP didn’t add a thirteenth receipt. It defined the layer that composes the other twelve.

A dozen efforts are racing to define “a receipt for an agent’s action,” and they have largely agreed on how to build one. The unclaimed ground is the verifier’s side: a single, offline way to combine them into a trustworthy decision. By owning composition — not competing on yet another format — EMILIA becomes the convergence point for the field rather than one of its entries.

See the landscape How the protocol fits

BOUNDED CLAIMS

What it proves — and what it doesn’t.

What an evidence chain proves

That, for one canonical action, every receipt presented binds that exact action, each verifies under its own rules, and the relying party’s composition requirement was met — checkable offline, by anyone, years later.

What it does not prove

That the underlying decision was correct, or real-world identity beyond each receipt’s own enrollment layer. AEC is a composition and verification object, not a judgment about the merits — and we state that plainly, because auditors and insurers are the buyers and an oversold claim is disqualifying.

STANDING

Filed, implemented, independently run.

EP-AEC is filed as an IETF Internet-Draft, draft-schrock-ep-authorization-evidence-chain, with a reference verifier in three languages — JavaScript, Python, and Go — that agree over portable conformance vectors. An outside implementer has independently run the EP artifacts from a clean machine and reported the result on the IETF SecDispatch list. It composes with the receipts already published across the cluster, including the EP authorization-receipts and quorum drafts.

Talk to us about composing your receipts

FREQUENTLY ASKED

Is EP-AEC just another receipt format?

No. It is deliberately not a 13th receipt. The field already converged on a common substrate for individual receipts; what was missing is the layer that composes several heterogeneous receipts for one action into a single offline verdict. AEC is that layer — a composition object plus a verifier with pluggable per-receipt checks.

What exactly does the verifier return?

A single fail-closed ALLOW or DENY for one canonical action, computed entirely offline. ALLOW requires that every presented receipt binds the same action, each verifies, and the relying party’s requirement (which receipt types must be present) is satisfied. Anything missing, mismatched, or unverifiable yields DENY.

How does it relate to DRP, permit receipts, or PSEA?

As complements, not competitors. Delegation (e.g. DRP), policy/permit, and decision receipts each answer their own hop; AEC verifies that those receipts — plus EP’s named-human authorization, the one leg the others do not supply — all bind the same action and verify together. It is the verifier-side convergence point for the cluster.

Does it need to be online?

No. Verification is fully offline and asymmetric: no introspection endpoint, no account, no trust in the issuer or operator. A chain stays verifiable even if EMILIA disappears.

Is this real, or just a draft?

It is filed as an IETF Internet-Draft (draft-schrock-ep-authorization-evidence-chain), with a reference verifier in three languages (JavaScript, Python, Go) that agree over portable conformance vectors. An outside implementer has independently run the EP artifacts from a clean machine and reported it on the IETF SecDispatch list.

An Authorization Evidence Chain proves that, for one canonical action, the receipts presented bind that action, each verify under their own rules, and a stated composition requirement was met — offline and without trust in the operator. It does not establish that the decision was correct, nor real-world identity beyond each receipt’s enrollment layer. Open standard (Apache-2.0), IETF Internet-Drafts; no production deployment claim implied.