EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

Security agent authorization evidence cross-domain human approval 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 identity, delegation and policy, material action matching, authorization evidence, evidence satisfaction, enforcement, outcome evidence, and long-term preservation. The architecture does not define a universal authorization policy and does not claim that a valid signature establishes authority. It defines where independently verified artifacts join, which decisions remain local to the relying party, and the terms VERIFIED, MATCH, SATISFIED, AUTHORIZED, and EXECUTED so that an implementation cannot silently collapse one into another.

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, and enforcement 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 also separates an interoperability requirement from ordinary implementation hygiene. For example, refusing a key supplied by an untrusted artifact from establishing its own authority is a baseline verifier property, not a new architectural layer. The architectural question is which independently verified facts a remote relying party needs, how those facts are bound to the same material action, and which party decides whether the resulting evidence is sufficient.

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 that can survive beyond the live interaction or operator boundary.

Decision 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 identifier 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. The evidence composition layer can compute this state.

AUTHORIZED:

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

EXECUTED:

An executor asserts or attests that an effect occurred. This is distinct from what was requested or authorized.

An implementation MUST NOT promote VERIFIED to MATCH, MATCH to SATISFIED, SATISFIED to AUTHORIZED, or AUTHORIZED to EXECUTED without performing the separate check that transition requires.

Layered Composition

Transport, Workload, and Agent Identity This layer establishes who or what is present in a live channel and how a workload credential is managed. WIMSE and related workload-identity work are examples. The evidence architecture consumes those results but does not redefine them.

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 receipts, 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 This layer answers whether independently represented artifacts concern the same material action. The candidate Canonical Action IDentifier specification defines a typed action object and an Action-Mapping Profile. A mapping result is one of EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, or INDETERMINATE. The mapping profile is selected and pinned by the relying party and cannot establish authorization.

Authorization and Confirmation Evidence This layer carries evidence that a specified approval ceremony or authorization event occurred. EMILIA authorization receipts, multi-party quorum records, presentation bindings, FIDO Verifiable Intent, 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 The Authorization Evidence Chain verifies each component using the component's native verifier and role-scoped trust anchors, checks that all required components MATCH the same action, and evaluates a relying-party-pinned requirement. Its result is SATISFIED or UNSATISFIED, not a universal authorization decision.

Challenge, Enforcement, Outcome, and Preservation An evidence challenge can state what is missing before an executor acts. The enforcement point applies local policy and refuses when required evidence is absent. Outcome evidence states what occurred after the effect boundary. Revocation and evidence records address lifecycle and long-term verification. Each is a separate transition and none is inferred from receipt validity. For a bounded capability, the enforcement point reserves budget before the effect boundary and commits it afterward as executed, delegated, or indeterminate. If an external effect may have occurred, uncertainty consumes budget rather than reopening authority for a duplicate effect.

Application Profiles Application profiles select action types, evidence requirements, trust anchors, freshness, consumption, and outcome rules for one deployment context. Agent Gateways, payments, healthcare, grid coordination, and model-directed laboratory execution can use the architecture without changing the core artifact formats. A profile does not make a domain claim true; it states the checks a deployment will perform.

Cross-Domain Verification Flow

1. The relying party identifies the proposed material action and pins its trust roots, mapping profiles, and evidence requirement.
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 action. Missing or lossy mappings yield INDETERMINATE and fail the requirement.
4. The evidence requirement is evaluated. A missing role, mismatched action, stale fact, invalid signature, or unpinned trust anchor yields UNSATISFIED with a reproducible reason.
5. The local policy enforcement point decides whether the SATISFIED evidence is sufficient to authorize execution.
6. Consumption and outcome evidence are recorded separately so replay and request-versus-effect divergence remain detectable.

EMILIA Component Boundaries

• draft-schrock-ep-authorization-receipts defines an action-bound authorization evidence artifact and verification profiles.
• draft-schrock-ep-quorum composes distinct approval ceremonies for multi-party requirements.
• draft-schrock-human-authorization-binding defines how human-authorization evidence binds into adjacent artifact families without replacing them.
• draft-schrock-canonical-action-identifier defines material action identity and profile-bounded matching.
• draft-schrock-ep-authorization-evidence-chain defines evidence composition and requirement satisfaction.
• draft-schrock-ep-bounded-capability-receipts defines a signed grant plus durable reserve-execute-commit profile for scoped, budgeted multi-operation authority. It is a separate experimental document. Its reference implementation provides implementation experience but does not yet claim conformance with that document's complete wire format.
• For that profile, native receipt verification can establish VERIFIED; scope containment returns profile-local in_scope, out_of_scope, or indeterminate, not MATCH. SATISFIED remains evidence sufficiency. AUTHORIZED requires local policy and a successful live reservation, and EXECUTED requires separately authenticated effect evidence.
• The action manifest, challenge, enforcement, outcome, revocation, and evidence-record documents address distinct lifecycle transitions. Their presence does not change the trust semantics of the core evidence artifacts.

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

• Linda Dunbar's individual DMSC Agent Gateway gap-analysis draft () provides a concrete cross-domain enforcement point: one gateway can enforce local policy while evidence remains verifiable outside either operator. This is a use case from an individual draft, not a claim of DMSC BoF consensus.
• WIMSE Condition-Bounded Credentials () establish workload identity and channel possession; portable authorization evidence can be bound to the same action without treating a workload credential as human approval.
• AuthZEN's Access Request and Approval Profile () defines requestable denial, asynchronous approval tasks, an approval object whose optional state carries opaque proof or verifier state, JWS interoperability when that state is carried by value, an exact-match baseline, and PDP re-evaluation at enforcement time. An EMILIA profile is complementary when a deployment requires a verifier-visible approver-held device ceremony, distinct-human quorum, portable initiator exclusion, cross-format material-action matching, or one-time executor consumption. None of those additional properties is implied merely by carrying an AuthZEN approval result.
• Mastercard's Verifiable Intent, co-developed with Google and contributed to the FIDO Alliance (), describes portable evidence of user intent. The cited page describes a contribution and prospective standardization, not a final FIDO specification. EMILIA does not claim that portable human evidence is absent; it defines additional action matching, quorum, consumption, and composition profiles where deployments require them.
• 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 policy ALLOW does not prove a named human approved. A matching action identifier does not prove either artifact is valid. A satisfied evidence requirement does not prove an action is lawful, safe, wise, or correctly executed. Trust anchors, role assignments, evidence requirements, mapping profiles, freshness limits, and consumption stores are relying-party inputs. They MUST NOT be silently imported from the artifact being judged. Implementations MUST fail closed when a required input is absent or unavailable. Human evidence remains vulnerable to coercion, fatigue, mis-rendering, compromised devices, and collusion. Device-bound user verification, exact-action presentation, initiator exclusion, and distinct-human quorum reduce specified threats but do not establish comprehension or correctness.

Changes from -00 This revision replaces the "human-authorization apex" framing with an ecosystem-first composition model; adds a concrete cross-domain applicability test; separates ordinary verifier hygiene from the portable-evidence requirement; defines the MATCH, VERIFIED, SATISFIED, AUTHORIZED, and EXECUTED vocabulary; introduces material action mapping; and narrows all claims to relying-party-pinned trust inputs and named verification profiles.

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 the concrete multi-operator use case. Chris Hood's agent transport and composition work helped clarify the boundary between carrying authority context and independently verifying evidence after the interaction. These acknowledgments do not imply endorsement of this document.