DOCUMENT 04 · EVIDENCE SATISFACTION · IETF INTERNET-DRAFT

One evidence result from many artifacts.

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. A relying party needs an explicit way to check that they all describe the same action, verify under their native rules, and fill its stated evidence requirement.

The Authorization Evidence Chain (EP-AEC) is that composition layer: an object and verifier that returns a fail-closed SATISFIED or UNSATISFIED evidence verdict. The executor separately decides whether to authorize the action.

Read AEC -05 Back to the four-document path

draft-schrock-ep-authorization-evidence-chain-05

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

THE GAP

Individual artifacts are not yet an evidence decision.

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.

The bundle needs its own result

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 — then evaluates them against its explicit evidence requirement.

Trust leaks in the gaps

Without a composite check, a relying party either trusts an operator to have stapled the right receipts together or risks accepting an artifact issued for a different action. AEC makes the action match and the evidence requirement explicit and inspectable.

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 evidence-satisfaction result. When required, it can compose named-human authorization evidence alongside machine-side delegation and policy receipts without redefining their native semantics.

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 SATISFIED or UNSATISFIED evidence verdict. Closed, stapled inputs need no EMILIA service call; the relying party still pins trust, freshness, and current-status rules. It separately decides whether to authorize execution.

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 exact material action and the stated evaluation inputs, the required artifacts verify under their native rules, match that action, and fill the relying party’s explicit evidence requirement.

What it does not prove

That the underlying decision was correct; real-world identity beyond each artifact’s enrollment layer; current status not supplied by the evaluation profile; local authorization; execution; or complete mediation. AEC is an evidence-satisfaction object, not a universal ALLOW.

STANDING

Filed, implemented, reproducibly tested.

EP-AEC -05 is filed as an individual IETF Internet-Draft, draft-schrock-ep-authorization-evidence-chain, with a reference verifier in three languages — JavaScript, Python, and Go, one team’s ports in one repository, a cross-language consistency check, not independent reimplementations — that agree over portable conformance vectors. An outside party reproduced a time-pinned EP conformance bundle and reported that result on the IETF SecDispatch list; that historical run is not silently extended to later AEC revisions or newly added vectors. 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 SATISFIED or UNSATISFIED evidence verdict for one exact material action. SATISFIED requires that each required artifact natively verifies, matches the action, and fills the relying party’s evidence requirement. It is not an ALLOW decision: the executor applies its own authorization policy separately.

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 can verify that those receipts, plus named-human authorization evidence when the relying party requires it, all bind the same action and verify together. It is a verifier-side composition point for the cluster.

Does it need to be online?

A closed bundle can be evaluated offline without an EMILIA account or service call. The relying party still chooses trusted issuers, keys, reference time, freshness, and any current-status evidence; a profile that requires live status can require network access.

Is this real, or just a draft?

Revision -05 is filed as an individual IETF Internet-Draft (draft-schrock-ep-authorization-evidence-chain), with a reference verifier in three languages (JavaScript, Python, Go) — one team’s ports in one repository, a cross-language consistency check, not independent reimplementations — that agree over portable conformance vectors. An outside party has reproduced the EP conformance suite against our published vectors 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 under relying-party-pinned evaluation inputs. It does not establish that the decision was correct, nor real-world identity beyond each receipt’s enrollment layer, local authorization, execution, or complete mediation. Open protocol (Apache-2.0), individual IETF Internet-Draft; no production deployment claim implied.