EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

Security agent authorization evidence cross-domain consequence control Consequential agent actions can cross operator and administrative boundaries. The party that later decides whether to rely on an action record may not have participated in the interaction and may not trust either operator. This document describes an evidence architecture for that case. It separates transport and workload identity, delegation and policy, material action identity, authorization evidence, evidence satisfaction, local authorization, durable consumption or reservation, effect invocation, outcome evidence, revocation, and preservation. The architecture composes the Canonical Action Identifier (CAID), Authorization Evidence Chain (AEC), and Action Evidence Boundary (AEB) with optional staged-approval and consequence-control profiles. It does not define a universal token, policy language, execution engine, settlement network, or distributed consensus system. A valid signature, a current credential, a satisfied evidence requirement, and an observed effect remain different facts.

Introduction An agent in one administrative domain can request a gateway in another domain to perform an action whose consequences are borne by a third party. Months later, an auditor, counterparty, insurer, or regulator may need to determine which identity, delegation, policy, approval, consumption, invocation, and outcome facts held for that exact action. An operator-controlled log can be useful operationally, but it is not by itself portable evidence against a dishonest or unavailable operator. This architecture addresses that cross-domain and delayed-review case. It is not required for every agent interaction. A deployment in one trusted administrative domain, with no need to export or preserve independently verifiable evidence, can use ordinary authentication, authorization, and logging. The architecture defines a narrow waist. Native artifact verifiers establish artifact-specific facts. CAID correlates material action content. AEC evaluates whether a relying-party requirement is satisfied. Local policy decides whether to authorize. AEB controls the transition from evidence to a consequential effect and retains uncertainty when an effect cannot yet be proved or disproved. Optional profiles can add staged approvals, bounded capability state, receipt-program execution, escrow-controlled release, attestation, witnesses, or domain-specific bindings without changing the meaning of the core decisions.

Applicability The architecture is useful when at least one of the following is true:

• the requester, executor, consequence owner, and later relying party are not all in one trust domain;
• an action can move money, change infrastructure, disclose protected data, create a legal or operational commitment, or cause a physical effect;
• authorization evidence must be verified after the live channel or originating operator is unavailable;
• one-time use, a budget, a deadline, staged approval, or separation of duties must be enforced across retries or replicas; or
• a provider can perform an effect and then fail to return a definitive response.

The architecture does not make a low-risk interaction consequential merely because an agent is involved.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Native verifier:

The verifier defined by an artifact's own specification, operating under trust anchors selected by the relying party.

Relying party:

The party that states an evidence requirement and decides whether to act on the verified facts.

Consequential action:

An action for which a deployment requires evidence and consequence controls that survive beyond the live interaction or operator boundary.

Effect boundary:

The point after which an external effect may have occurred and a transport failure can no longer safely be interpreted as no effect.

Consequence owner:

The one configured state machine responsible for claiming, invoking, and recording the outcome of a protected external effect.

Trust Program:

An optional relying-party-controlled orchestration profile in which verified evidence fills ordered or thresholded stages before one consequence owner can receive a fenced execution claim. Some implementations use the term Authority Program for the same pattern.

Receipt Program:

An optional consequence-owner profile that freezes one CAID-bound instruction, executes through a configured Gate, and emits a terminal certificate only after the Gate outcome and evidence-log transition succeed.

Decision and Lifecycle Vocabulary Conforming descriptions and APIs MUST keep the following states distinct:

VERIFIED:

An artifact passed its native cryptographic and structural verification under relying-party-selected trust anchors. It does not follow that the artifact filled an authorization role.

MATCH:

Two independently verified artifacts refer to the same material action, either by direct CAID equality or by an explicit, pinned mapping profile. MATCH is content correlation, not authorization.

SATISFIED:

The verified and matched evidence fills every slot in a relying-party-pinned evidence requirement. AEC can compute this state.

AUTHORIZED:

The relying party's local policy permits an attempted execution. This is a business and policy decision; no presented artifact establishes its own authority.

RESERVED or CONSUMED:

Durable state has fenced the operation's one-time authority, capability budget, or equivalent right before provider entry. This is not evidence that an effect occurred.

INVOKED:

The consequence owner durably records that provider entry has begun or may have begun. From this point, an exception or missing response cannot safely reopen authority.

EXECUTED:

Authenticated outcome evidence establishes that the bound effect occurred. This is distinct from what was requested or authorized.

FAILED:

Authenticated outcome evidence establishes that the bound effect did not occur or was definitively refused. A transport exception after provider entry is not sufficient for this state.

INDETERMINATE:

The effect may have occurred but current evidence establishes neither EXECUTED nor FAILED. Blind replay is unsafe.

RECONCILED:

Authenticated provider or system-of-record evidence resolves an INDETERMINATE operation to EXECUTED or to a proved-no-effect result. Reconciliation does not invoke the effect again.

An implementation MUST NOT promote VERIFIED to MATCH, MATCH to SATISFIED, SATISFIED to AUTHORIZED, AUTHORIZED to RESERVED or CONSUMED, RESERVED or CONSUMED to INVOKED, or INVOKED to a terminal outcome without performing the separate check and durable transition that step requires.

Architectural Invariants

Relying-Party-Controlled Trust Inputs Trust anchors, verifier profiles, role assignments, evidence requirements, CAID mapping profiles, freshness limits, revocation policy, clocks, consumption stores, consequence owners, and outcome verifiers are relying-party inputs. They MUST NOT be selected or weakened by the artifact being judged or by transaction-scoped requester input.

Native Verification Before Correlation An artifact MUST pass its native verifier before any label, digest, or claimed relationship from that artifact is used for CAID matching or evidence satisfaction. A CAID does not repair an invalid native signature, an untrusted issuer, a stale credential, or an invalid native policy result.

One Material Action Across the Chain The action presented for approval, the action selected by local policy, the action used for capability reservation, the action passed to the consequence owner, and the action named by outcome evidence MUST resolve to the same CAID or to a mapping result accepted under one exact relying-party-pinned profile. Missing, lossy, or ambiguous mappings are INDETERMINATE and cannot establish MATCH.

Durable State Before Effect When a deployment requires one-time use, a budget, staged approval, or no-blind-retry behavior, the authoritative state transition MUST be durable and atomic across replicas before provider entry. Process-local state is suitable only for explicit test or demonstration profiles.

Uncertainty Is Retained Before provider dispatch, the consequence owner MUST durably record enough invocation intent that recovery can distinguish an uninvoked operation from one that may have crossed the effect boundary. On restart, any operation for which provider entry cannot be disproved MUST become or remain INDETERMINATE. It MUST NOT silently return to an executable state.

Complete Mediation The architecture controls only paths that traverse the configured enforcement point and consequence owner. A valid evidence chain or program state cannot prevent an administrator, alternate API, direct credential, or external payment path from bypassing that control. Non-bypassability is a deployment property.

Layered Composition

Transport, Workload, Agent, and Human Identity This layer establishes who or what is present in a live channel, how a workload or agent credential is managed, and which human or organization a relying party has bound to a key. WIMSE and related workload-identity work are examples. The evidence architecture consumes those results but does not redefine them. A current credential answers an identity or status question. It does not by itself prove that its subject authorized one exact action, that a human rather than an agent operated the key, or that local policy permits the consequence.

Delegation, Capability, and Policy This layer establishes what a principal delegated, what a capability permits, and what a policy decision point allowed. OAuth profiles, delegation artifacts, AuthZEN, and agent transport work occupy parts of this layer. A machine policy decision is not represented as human approval unless a separately defined and verified approval artifact establishes that fact. A bounded capability combines an immutable signed grant with mutable shared state. Receipt verification establishes the grant; action-scope matching and an atomic reserve/commit transition establish whether one operation can consume part of its budget. A signed budget without one authoritative state domain cannot enforce aggregate spend across replicas.

Material Action Identity and Mapping CAID names typed material action content. Direct equality is byte-level content equality under the selected CAID suite. Cross-format comparison requires an Action-Mapping Profile selected and pinned by the relying party. A CAID carries no identity, authorization, capability, execution, or outcome semantics.

Authorization and Confirmation Evidence This layer carries evidence that a specified approval ceremony or authorization event occurred. EMILIA authorization receipts , multi-party quorum records , and other confirmation artifacts can occupy this layer under their own guarantees. No single artifact is assumed to fill every relying-party requirement.

Evidence Composition and Satisfaction AEC verifies each component using the component's native verifier and role-scoped trust anchors, checks that all required components MATCH the same material action, and evaluates a relying-party-pinned requirement. Its result is SATISFIED or UNSATISFIED, not a universal authorization decision and not an execution result.

Optional Staged Trust Programs A Trust Program can require several evidence stages, including ordered dependencies, heterogeneous thresholds, and separation of duties. Each stage consumes bounded results from registered native verifiers and can issue a signed stage receipt bound to the program, action, stage policy, predecessor receipts, and accepted evidence. A passing stage proves only that the configured technical evidence rule was satisfied. It does not upgrade weak native evidence, prove civil identity, or make an action lawful. A completed Trust Program can fence one claim for one selected consequence owner; it does not perform the external effect. This document defines the architectural role, not a Trust Program wire format.

Action Evidence Boundary AEB joins native verification, CAID MATCH, AEC SATISFIED, local AUTHORIZED, durable reservation or consumption, provider invocation, closed outcomes, and authenticated reconciliation. AEB is a lifecycle and enforcement boundary; it is not another receipt, credential, universal policy language, or evidence registry.

Outcome, Revocation, and Preservation Outcome evidence states what occurred after the effect boundary. Revocation states that named authority or evidence is no longer valid from an effective time. Preservation mechanisms retain verifiability as systems, operators, and algorithms change. Each answers a separate question, and none is inferred from receipt validity.

Application and Consequence Profiles Profiles select action types, evidence requirements, trust anchors, freshness, consumption, consequence ownership, outcome, and reconciliation rules for one deployment context. Agent gateways, payments, healthcare, infrastructure, and physical systems can use the architecture without changing the core artifact formats. A profile does not make a domain claim true; it states the checks and mediation boundary a deployment will apply.

End-to-End Verification and Consequence Flow

Non-collapsing action lifecycle MATCH -> SATISFIED -> AUTHORIZED | reserve or consume | v RESERVED / CONSUMED | record invocation intent | v INVOKED / | \ / | \ EXECUTED FAILED INDETERMINATE | authenticated reconcile | executed or proved-no-effect ]]>

1. The relying party derives the proposed action from executor-controlled facts and pins trust roots, verifier profiles, CAID suites or mapping profiles, evidence requirements, freshness, revocation policy, and the consequence owner.
2. Each identity, delegation, policy, and approval artifact is verified by its native verifier. Presenter-supplied keys or labels do not create authority.
3. Verified artifacts are matched to the exact action. Missing or lossy mappings yield INDETERMINATE and fail a required MATCH.
4. AEC evaluates the evidence requirement. A missing role, mismatched action, stale fact, invalid signature, or unpinned trust anchor yields UNSATISFIED with a reproducible reason.
5. An optional Trust Program admits the bounded native results into one or more stages. Otherwise, the relying party proceeds directly to local policy.
6. The local enforcement point decides whether the satisfied evidence is sufficient to authorize an attempted execution.
7. The authoritative state store atomically reserves or consumes the operation before provider entry. Failure to durably fence the operation is a refusal.
8. The consequence owner durably records invocation intent and then invokes the provider. Recovery MUST conservatively classify a stranded operation as INDETERMINATE unless non-entry is established.
9. Authenticated owner or provider evidence records EXECUTED, FAILED, or INDETERMINATE. An exception after possible provider entry is INDETERMINATE, not a refund or retry grant.
10. Authenticated reconciliation can resolve INDETERMINATE without invoking the action again. Evidence records, revocation statements, and preservation artifacts remain separate, linked records.

Programs and Multi-Stage Authorization

Trust Program A Trust Program addresses approvals in which one rule cannot be reduced to a single signature or a flat M-of-N quorum. A program can require, for example, a department approval followed by a compliance approval, with a later finance stage unlocked only by signed receipts from both predecessors. Each stage binds the same root CAID and action digest plus the exact predecessor stage-receipt digests. Stage thresholds apply to heterogeneous evidence seats. A native human quorum remains one natively verified quorum component; a Trust Program MUST NOT decompose several unverified labels and relabel them a quorum. Likewise, a stage receipt MUST NOT be treated as execution evidence.

Receipt Program A Receipt Program addresses a different problem: executing one already authorized and bounded instruction. A reference profile can bind the exact instruction, CAID, stable operation identifier, capability projection, executor selector, deadline, and result projection; call the configured Gate's reserve-before-effect path; and issue a terminal certificate over the resulting step sequence and linked Gate evidence. A Receipt Program is not an approval workflow, a smart contract, or proof that the external result is true. Its certificate is no stronger than the configured Gate, consequence owner, signer custody, evidence log, outcome evidence, and non-bypassability of the provider path.

Single Consequence Ownership For one operation, exactly one configured consequence owner is responsible for provider entry and effect-outcome state. A Trust Program may select a Receipt Program or an Action Escrow release profile as that owner, but the two MUST NOT recursively claim or execute the same effect. Selection, claim, invocation, and outcome are separate transitions.

Optional Consequence-Control Profiles

Bounded Capability Bounded Capability Receipts describe a signed exact-scope grant plus durable mutable state for registration, reservation, and commitment. The profile can limit amount, unit, currency, deadline, delegation, and operation identity. It does not define settlement, and signed bytes alone do not enforce a shared budget.

Action Escrow An Action Escrow profile can bind final agreement bytes, structured material terms, party roles, milestone evidence, exact release action, funding evidence, and a custodian result into one closed release state machine. A release is reserved before provider entry. An ambiguous provider result remains release-indeterminate until authenticated custodian reconciliation. Reference implementation experience exists for document binding, durable release state, evidence packaging, and bounded external adapters. That experience does not make EMILIA a custodian, escrow provider, settlement network, legal adjudicator, or source of truth for off-platform effects. Licensing, custody, solvency, legal enforceability, and provider finality remain outside this architecture.

Distributed Trust Computer Deployment Pattern The term Distributed Trust Computer (DTC) is used by some implementations for a deployment pattern that composes action identity, authorization evidence, local policy, bounded authority, durable consequence control, terminal evidence, and optional independent witnesses or platform attestation. The distribution is of trust evidence and control roles; this architecture does not require a blockchain or consensus protocol. DTC is not a wire protocol defined by this document. The repository contains reference building blocks for several parts of the pattern, including Gate enforcement, CAID, AEC, bounded capabilities, Receipt Programs, Action Escrow, witness verification, and build-attestation verification. Their composition is not, by itself, evidence of a deployed DTC, independent operators, physical-hardware attestation, cross-vendor interoperability, or settlement finality.

Revocation, Disputes, and Compensating Actions

Revocation and Current Status A portable revocation statement can establish that a pinned revoker invalidated one exact target at an effective time. A pre-claim revocation can prevent new authority from advancing. A revocation learned after provider entry does not rewrite an effect as though it never happened. Possession of no revocation statement is not proof of current non-revocation. A relying party that requires current status needs a fresh authenticated status view with completeness and rollback properties appropriate to its deployment.

Disputes A dispute records that a party contests an authorization, outcome, amount, quality, or other fact. Opening a dispute does not prove either side correct, revoke a credential, reverse an external effect, or grant authority for a remedy. Dispute evidence therefore remains separate from the original immutable action record.

Compensating Actions A return, refund, rollback, cancellation, or other remedy that creates an external effect is a new consequential action. It needs its own action object, CAID, authorization evidence, operation identifier, consequence owner, outcome, and reconciliation path. A remedy links to the original action but does not mutate it.

Component Boundaries and Implementation Status The following status descriptions are intentionally narrower than the architecture:

• defines an action-bound authorization evidence artifact and verification profiles. It is a published individual Internet-Draft, not an RFC or adopted standard.
• composes distinct approval ceremonies for multi-party requirements. It is a published individual Internet-Draft.
• defines material action identity and profile-bounded matching. It grants no authority. It is a published individual Internet-Draft.
• defines evidence composition and requirement satisfaction. It does not make the local authorization or execution decision. It is a published individual Internet-Draft.
• defines a signed grant plus durable reserve-execute-commit profile for scoped, budgeted multi-operation authority. It is a published experimental individual Internet-Draft.
• defines the effect-boundary lifecycle and enforcement composition. At the time of this revision it is a companion individual-draft proposal, not an adopted standard.
• defines a portable terminal revocation statement. Its reference verifier and vectors provide implementation experience, but they do not prove availability or completeness of current status information.
• is an Experimental executor-side application profile over CAID, AEC, and AEB. Its reference implementation and synthetic vectors do not establish a wet-lab deployment, scientific validation, physical truth, partner, or endorsement.
• Gate enforcement, Receipt Programs, and Action Escrow have reference implementation profiles. A development Trust Program build supplies implementation experience for staged orchestration. This architecture does not standardize those APIs, claim independent implementations, or assert that any specific deployment completely mediates all consequential paths.
• DTC names a broader deployment pattern. It is not a protocol or a deployment claim in this document.

Relationship to Adjacent Work The architecture is designed to compose with, rather than absorb, adjacent work:

• The DMSC Agent Gateway gap-analysis draft provides concrete multi-domain and physical-action gateway scenarios. It is an individual draft, not a claim of IETF consensus.
• WIMSE Condition-Bounded Credentials establish workload identity and channel-possession properties. They do not by themselves establish per-action human authorization.
• WIMSE HTTP Signatures protect selected end-to-end HTTP material. An AEB profile must distinguish signed end-to-end action fields from intermediary context that is legitimately mutable or removable.
• WIMSE Authorization Evidence defines transport of authorization evidence in workload-mediated HTTP. AEC and AEB can consume such evidence through its native verifier without redefining the carrier.
• AuthZEN's Access Request and Approval Profile defines asynchronous approval tasks and policy-decision-point re-evaluation. EMILIA profiles are complementary when a deployment requires portable exact-action evidence, distinct human ceremonies, durable consumption, or consequence reconciliation. Those properties are not implied by a generic approval result.
• FIDO Verifiable Intent describes portable evidence of user intent. The cited page describes a contribution and prospective standardization, not a final FIDO specification.
• KLRC agent authentication separates agent credentials and their lifecycle from application semantics. Credential validity and per-action authorization remain separate in this architecture.
• AGTP carries agent identity, authority, attribution, and application payloads at the wire layer. This architecture defines evidence that can be carried or referenced by that transport and checked after the live channel is gone.

Security Considerations The primary architectural failure is category collapse. A valid signature can authenticate an untrusted assertion; it does not make the assertion authoritative. A current credential does not prove a human approved one exact action. A policy ALLOW does not prove a named human approved. A matching CAID does not prove either artifact is valid. A satisfied evidence requirement does not prove an action is lawful, safe, wise, or correctly executed. Trust inputs MUST NOT be silently imported from the artifact being judged. Native verifier exceptions, missing trust configuration, stale status, store unavailability, signer failure, or ambiguous effects must fail closed while preserving a reason suitable for recovery and audit. Consumption and reservation state must resist replay, rollback, concurrent writers, replica divergence, operation relabeling, and caller mutation. A provider idempotency key reduces duplicate effects but does not replace local atomic state or authenticated reconciliation. Human evidence remains vulnerable to coercion, fatigue, mis-rendering, compromised devices, and collusion. Device-bound user verification, exact-action presentation, initiator exclusion, staged programs, and distinct-human quorum reduce specified threats but do not establish comprehension or correctness. Optional witness or platform-attestation evidence is bounded by the independence of operators, enrollment of keys, measured-build policy, freshness, and verifier correctness. A same-operator witness or software TPM fixture must not be described as independent or physical-hardware proof.

Privacy Considerations Action objects and evidence chains can expose identities, relationships, amounts, destinations, medical or employment context, infrastructure topology, and business intent. CAID is a digest-based identifier, not an anonymization mechanism; low-entropy action spaces can permit guessing. Profiles SHOULD minimize portable fields, prefer pairwise identifiers where correlation is not required, separate evidence references from raw source records, define retention and disclosure policy, and avoid placing secrets or bearer claim tokens in logs. Selective-disclosure mechanisms do not remove the need to bind every disclosed projection to the exact action and relying-party requirement.

Operational Considerations Production profiles need durable state, stable operation identifiers, clock monitoring, key custody, trust-root rotation, authenticated status and outcome sources, retention controls, and explicit recovery for INDETERMINATE operations. Test-only in-memory stores, generated keys, local witnesses, and software attestation fixtures must be visibly separated from production configuration. Operators SHOULD expose the distinct lifecycle verdicts and refusal reasons rather than one boolean "authorized" field. Monitoring SHOULD alert on repeated indeterminate outcomes, stale revocation views, reconciliation backlog, store conflicts, signer failures, and attempted bypass of the configured consequence owner.

Changes from -01 This revision:

• makes CAID, AEC, and AEB the explicit continuity core;
• extends the vocabulary with durable reservation, invocation, indeterminate outcome, and reconciliation states;
• adds the recovery invariant that possible provider entry cannot return silently to an executable state;
• adds optional staged Trust Programs and distinguishes them from Receipt Programs;
• defines single consequence ownership and profiles bounded capabilities, Receipt Programs, and Action Escrow without changing core artifact formats;
• describes DTC as a deployment pattern, not a deployed protocol or consensus system;
• clarifies pre-claim and late revocation, disputes, and compensating actions; and
• adds explicit implementation-status, privacy, and operational claim boundaries.

IANA Considerations This document has no IANA actions.

Normative References Informative References FIDO Alliance

Acknowledgments Eric Rescorla's review prompted a sharper separation between baseline verifier security properties and the specific need for third-party, cross-domain validation. Linda Dunbar's Agent Gateway scenarios supplied a concrete multi-operator use case. Discussion of WIMSE signatures and authorization evidence sharpened the boundary between end-to-end signed material and mutable intermediary context. Work on agent credentials, authorization transports, and agent transfer helped clarify why identity, policy, action evidence, execution, and outcome remain separate. These acknowledgments do not imply endorsement of this document.