| Internet-Draft | Action Evidence Boundary | September 2026 |
| Schrock | Expires 28 March 2027 | [Page] |
Consequential agent actions can cross identity, transport, authorization, policy, and execution systems. Each system can produce a valid artifact while the executor still lacks a safe rule for joining the artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. This document defines the Action Evidence Boundary (AEB), an executor-side processing model for that lifecycle.¶
AEB requires native artifact verification, exact-action binding, a relying-party authorization decision, stable replay identity, durable atomic consumption or reservation, provider entry, closed effect outcomes, and authenticated reconciliation. CAID matching is used when independently encoded native representations must be joined. AEC is used when local policy requires multiple evidence legs. A native authorization decision accepted and enforced by the effect-owning PEP does not require a second PDP. AEB defines no receipt or token format, no policy language, no universal evidence taxonomy, and no new registry. Native workload credentials, OAuth artifacts, AuthZEN decisions, AP2 mandates, message signatures, permits, authorization receipts, and status mechanisms retain their own semantics and verifiers.¶
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 28 March 2027.¶
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.¶
A remote executor can receive several independently useful inputs: a workload credential and protected request, a delegation or capability, a pre-execution permit, a human-authorization artifact, and a policy decision. None of those inputs alone answers every question the consequence-owning system has to answer before changing its system of record.¶
The missing contract is at the effect boundary after authorization. The executor must determine what exact material action it is about to perform; verify each native artifact; preserve the authorization result produced by the selected native path; correlate independently encoded representations without guessing when such a join is required; derive a stable replay identity; consume or reserve any one-time or bounded authority; enter the provider once; and preserve uncertainty when the effect cannot be observed conclusively.¶
This document defines that contract. Its required order is:¶
native verification
|
v
exact-action correspondence
(native binding, or CAID for a cross-format join)
|
v
additional evidence SATISFIED when required
(AEC for a multi-leg requirement)
|
v
native PEP or local AUTHORIZED
|
v
stable native replay identity
|
v
atomic CONSUMED / RESERVED
|
v
durable DISPATCH_PENDING at provider entry
|
v
INVOKED
|
+--> EXECUTED
+--> FAILED
+--> INDETERMINATE --> authenticated reconciliation
¶
The CAID and AEC stages are conditional. A native authorization path can bind one operation directly and satisfy the relying party without a cross-format join or a multi-leg requirement. A signature is not authority. Native verification is not action correlation. Action correlation is not evidence satisfaction. Evidence satisfaction is not authorization. Authorization is not provider entry or execution. An invocation error is not proof that no effect occurred.¶
AEB specifies processing requirements for a boundary that controls a consequential effect. It can be implemented at a protocol gateway, service mesh component, application middleware, execution adapter, or system-of-record write path, provided the deployment states which effect paths the boundary actually mediates.¶
AEB does not define:¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
BCP 14 is indexed by the RFC Editor at [BCP14].¶
AEB uses the following decisions with the meanings established by the EMILIA architecture and its component drafts:¶
AEB also names operational lifecycle states:¶
CONSUMED, RESERVED, DISPATCH_PENDING, INVOKED, FAILED, and INDETERMINATE are lifecycle terms, not new evidence types or IANA registry values. A deployment MAY use different local labels if their semantics are at least as strict.¶
The requester, presenter, agent, and mutable intermediary context are untrusted inputs. They MAY propose an action and present native artifacts. They MUST NOT select or weaken the controls used to accept that request.¶
Before evaluating an action, the relying party MUST configure or pin, as applicable:¶
A label, key, profile identifier, requirement, status assertion, or policy identifier carried only in presenter-controlled data MUST NOT become its own trust anchor. Missing, conflicting, unsupported, or ambiguous required configuration MUST fail closed.¶
The effect boundary MUST construct an immutable observed action from effect-relevant facts it controls. Depending on the application, those facts can include the protocol operation, tool or method, target resource, tenant, account, amount, currency, destination, environment, input digest, and unique operation identifier.¶
The boundary MUST resolve the exact native operation profile used for authorization and include every field that profile makes material to the protected consequence. When a cross-format join is required, it MUST also resolve a relying-party-pinned CAID action-type definition and include every field that definition declares material. It MUST NOT copy a requester-supplied action digest, CAID, amount, destination, or resource reference without deriving or checking the corresponding fact at the protected boundary. If the boundary cannot determine all material fields required by the selected native or cross-format profile, it MUST refuse before invocation.¶
The observed action MUST be frozen for the remainder of the lifecycle. A later adapter MUST NOT reconstruct a different action from mutable request state after authorization.¶
When emitting or comparing a CAID, the boundary MUST validate the constructed action against the complete pinned action-type definition. A source representation is construction-compatible only when a pinned mapping can derive every material target field without guessing. Construction compatibility is distinct from content equivalence: compatible inputs can still map to different actions, while a missing, ambiguous, or unverified material field yields INDETERMINATE. A boundary that does not perform a cross-format join still MUST preserve the native protocol's exact-operation binding through provider entry.¶
Each required native artifact MUST be verified independently under its own specification and relying-party-selected trust inputs before CAID mapping or AEC evaluation. The AEB implementation MUST use the integrity-protected payload returned by the native verifier, or a projection for which the adapter establishes integrity coverage of every projected field.¶
A successful signature check is only one possible step of native verification. Schema, algorithm, issuer, audience, key status, validity, proof-of-possession, freshness, replay, and native policy checks remain those of the selected native profile. A verifier exception, unavailable required status source, unsupported critical field, or ambiguous result MUST become a bounded refusal, never an allow path.¶
The output of this stage is VERIFIED for each accepted artifact. An artifact that has not reached VERIFIED MUST NOT participate in a selected action mapping or fill a selected AEC requirement slot.¶
The boundary MUST establish that the exact operation authorized by the selected native path is the operation that will enter the provider. When both are expressed in one native representation, the boundary MAY use the exact native identifier, digest, or protected operation fields defined by that protocol.¶
When the boundary joins independently encoded representations, it MUST recompute the CAID of the observed action under the selected suite and definition source. It MUST compare every action-bound required artifact to that observed action using direct CAID equality or the Action-Mapping Profile defined by [CAID].¶
Cross-format mapping MUST occur only after native verification and MUST use the exact source media type, schema version, target action type, definition source, and mapping-profile digest pinned by the relying party. Every target material field MUST be covered. Missing, lossy, unknown, unpinned, conflicting, or ambiguous mappings yield INDETERMINATE under CAID and MUST fail a required MATCH. AEB MUST NOT guess equivalence from names, natural-language descriptions, trace identifiers, or presenter assertions.¶
CAID is conditional machinery for a cross-format join, not a second authorization protocol. MATCH is content correlation only. It does not validate a native artifact and does not authorize execution.¶
A relying party MAY require a natively verified field-origin assertion for selected fields before admission. This document defines the processing contract for that input, not a field-origin wire format, origin taxonomy, scanner, or transformation language.¶
The boundary MUST verify the assertion under the relying party's pinned native verifier, issuer and key, assertion profile and digest, action binding, field selectors, accepted origin classes, accepted transformation definitions, snapshot policy, freshness bound, and status inputs. The verifier output MUST bind each asserted field to the exact observed action or to a lossless, pinned mapping to that action. A profile identifier or origin label carried only by the presenter MUST NOT select its own verifier or trust root.¶
A verified assertion establishes that the pinned issuer made the signed claim. It does not independently prove source truth, semantic correctness, absence of prompt injection, authorization, settlement, or the truth of a later physical effect. If policy requires an origin constraint for a material field, a missing assertion, unknown or disallowed origin, unpinned transformation, stale or unreliable required snapshot, action mismatch, or unavailable required status MUST withhold admission. The boundary MUST preserve the distinction between assertion verification and acceptance under local policy.¶
A field-origin policy SHOULD be discriminating rather than a blanket prohibition on untrusted content. For example, it can refuse an untrusted message that selects a payee or destination while accepting the same origin class for a bounded non-authoritative memo field. The accepted and refused field classes are relying-party policy, not universal AEB semantics.¶
EP-FIELD-ORIGIN-v0.1 and its finance-operations Gap 6 runner
are an informative reference implementation profile
[EP-FIELD-ORIGIN]. They do not become a mandatory AEB
format and their same-team results are not independent implementation
evidence.¶
AEB does not require an AEC evaluation when one native authorization result, enforced by the effect-owning PEP, satisfies the relying party's complete requirement. When local policy requires multiple evidence legs, the boundary MUST submit only natively verified, action-matched evidence to an AEC verifier configured with the relying party's requirement. The requirement used for the decision MUST come from relying-party configuration, not from a presenter-controlled AEC member.¶
Every required evidence role MUST be filled by an artifact whose native verifier and adapter are accepted for that role. A workload identity MUST NOT silently fill a policy-permit or human-authorization slot. A machine-policy decision MUST NOT silently fill a named-human slot. A generic operator signature MUST NOT be interpreted as evidence that a human operated a system or performed a named approval ceremony.¶
When AEC is selected, only a successful evaluation under these inputs reaches SATISFIED. UNSATISFIED, malformed, unsupported, or ambiguous results MUST withhold invocation. AEB MUST NOT insert an AEC leg merely to re-decide or relabel one native PDP result.¶
A qualification statement can fill an evaluation-evidence role only when its native verifier establishes the measured candidate, evaluation campaign, assignment, policy, freshness, and status. A qualification result MUST NOT fill an authorization role and MUST NOT by itself cause SATISFIED, AUTHORIZED, reservation, or invocation.¶
The consequence-owning relying party MUST pin every adapter revision, trust root, mapping profile, evidence requirement, and boundary constraint used for a decision. The presenter MUST NOT select or weaken those inputs. The following EP-AEB-REQUIREMENT-v1 object is an optional closed profile for a deployment that selects AEC and multiple evidence roles. It is not required for a single native authorization path:¶
{
"@version": "EP-AEB-REQUIREMENT-v1",
"all_of": ["human-authorization", "policy-permit"],
"terms": [
{ "type": "distinct-human-quorum",
"role": "human-authorization", "threshold": 2 },
{ "type": "initiator-exclusion",
"roles": ["human-authorization"] },
{ "type": "executor-exclusion",
"roles": ["human-authorization"] },
{ "type": "one-time-consumption" }
]
}
¶
An implementation of this optional object MUST reject unknown terms.
It MUST require exactly one one-time-consumption term. A
distinct-human-quorum term counts only distinct natural-person
subject identifiers exposed by eligible native verifiers for the named
role. initiator-exclusion and executor-exclusion compare
those verified subjects with the boundary-owned initiator and executor
identifiers. Different encodings of one key or subject MUST NOT count as
different humans.¶
Execution-time evaluation MUST resolve current status through relying-party-configured status sources. Presenter-supplied current status is untrusted. Revoked, expired, stale, unavailable, ambiguous, or unauthenticated required status MUST withhold authorization. Historical re-performance MUST be labeled historical and MUST NOT be used as a current execution decision.¶
The evaluator SHOULD emit a signed, re-derivable record binding the observed action and, when selected, its CAID; operation and consumption identifiers, initiator and executor, adapter and mapping revisions, complete requirement and configuration digests, native artifact digests, current-status snapshots, per-leg VERIFIED and MATCH results, AEC SATISFIED, boundary constraints, and the separate AUTHORIZED or REFUSED verdict, as applicable. A record that omits a conditional CAID or AEC stage MUST identify the native exact-operation binding and the reason the extra stage was not selected. The record is evidence of the evaluator's decision; it does not itself perform or authorize an effect.¶
Before consuming or reserving authority, the boundary MUST derive a stable replay identity from the verified native authorization or from the executor-owned exact operation under a relying-party-pinned profile. The same native authority presented in a new wrapper, task, session, trace, challenge, or caller retry MUST yield the same replay identity.¶
The replay identity MUST NOT be derived from a caller-selected retry identifier, an AEB wrapper digest, or other mutable context that can make the same authority spendable again. If the selected native profile cannot provide or support a stable derivation, the boundary MUST refuse provider entry.¶
After AUTHORIZED and stable replay derivation, and before provider entry, the boundary MUST perform the durable state transition required by the native evidence and local policy. This can include consuming a one-time authorization, challenge nonce, or operation key; reserving a bounded capability or budget; and fencing the operation to one owner across replicas.¶
The transition MUST be atomic within the relying party's durable state domain. The operation record MUST bind the stable replay identity to the executor-owned observed action or operation identifier, never a presenter-selected decoy. Independently of that composite operation record, the store MUST enforce uniqueness or conflict detection for every stable native replay identity that the selected profile marks as one-time. Changing an operation identifier MUST NOT make the same one-time native authority reservable again. If the store is unavailable, non-atomic, stale, or reports an ambiguous result, the boundary MUST refuse before invocation.¶
AEB does not claim atomicity between a local store and an unrelated remote provider. It requires the local consume or reserve transition to occur first so that any uncertainty after dispatch cannot make the same authority available for an uncontrolled second effect.¶
An authorized MCP tool call, API request, or other protocol operation is not automatically proof that an underlying provider effect was authorized or occurred. When the authorized operation is itself the protected provider mutation, the same frozen action can continue through this lifecycle. When an MCP server, API service, or intermediary makes a distinct downstream provider request, the boundary MUST bind that provider request to the authorized operation under the selected native profile or a pinned cross-format mapping. It MUST NOT infer that binding from a session, trace, tool name, or natural-language description.¶
Before any call, message, or byte can reach an effecting component, the boundary MUST durably enter DISPATCH_PENDING for the frozen observed action that reached AUTHORIZED and CONSUMED or RESERVED. The record MUST bind the action digest, operation identifier, provider environment, audience, reservation or consumption record, and adapter. Failure or ambiguity while writing this record MUST withhold dispatch.¶
The boundary MUST invoke only from that durable state. It MUST use a stable, action-bound, unique operation identifier or idempotency key where the provider supports one. After dispatch begins, it MUST durably record INVOKED or a terminal outcome before reporting success to the requester.¶
The adapter MUST receive only the authority and evidence necessary for the downstream interface. It MUST NOT accept mutable intermediary or caller context that changes a material field after the boundary's authorization decision.¶
After invocation begins, the boundary MUST classify the result as EXECUTED, FAILED, or INDETERMINATE. On restart, a DISPATCH_PENDING operation without an authoritative terminal record MUST be promoted to INDETERMINATE before any retry or release, because the process cannot establish that dispatch did not begin.¶
For EXECUTED, the boundary MUST commit any reserved spend and preserve the terminal evidence. For FAILED, it MUST preserve the failure evidence and follow the native reservation policy. For INDETERMINATE, it MUST preserve or consume the reservation, refuse reuse of the authorization and operation identifier, and prohibit a blind replay.¶
An INDETERMINATE operation, including one recovered from a stranded DISPATCH_PENDING record, MUST remain closed until reconciliation authenticates the provider or system of record and matches the result to the original action, operation identifier, provider environment, audience, target resource, and every application-specific material field.¶
Reconciliation MAY move INDETERMINATE to EXECUTED when authoritative evidence establishes that the exact effect occurred. It MAY move INDETERMINATE to FAILED when authoritative evidence establishes that it did not occur. Missing, stale, conflicting, unauthenticated, or action-mismatched observations MUST leave the operation INDETERMINATE.¶
Reconciliation MUST NOT resurrect the original authorization or silently release its one-time replay unit. If policy permits a later attempt after an authoritative FAILED result, that attempt MUST use a new action instance and complete the lifecycle required by local policy. An implementation MUST NOT invoke again merely because a timeout elapsed or because the caller retried.¶
A deployment MAY publish a static declaration describing protected actions, material fields, evidence requirements, challenge methods, and effect-boundary placement. Such a declaration is discovery metadata. It MUST NOT override the relying party's live, local enforcement configuration. An unsupported declaration version MUST be ignored as discovery input; it cannot weaken or replace live enforcement. An action that the live boundary configuration cannot classify or process under a supported version MUST fail closed.¶
When required evidence is absent or unacceptable, a boundary MAY use its application protocol to return a dynamic challenge. A challenge MUST identify the boundary-computed action, the missing evidence roles, the policy context, an intended audience, a short expiry, and a single-use unpredictable nonce or equivalent replay unit. The nonce MUST NOT be consumed merely because untrusted bytes parse. It MUST be consumed atomically only after the selected native verifier establishes the integrity and challenge binding of an in-window presentation, and before that presentation can reach SATISFIED or authorize an effect. A presentation that is malformed, unauthenticated, expired, or not bound to the challenge MUST be refused without burning the nonce. A natively verified, challenge-bound presentation consumes the nonce whether or not the remaining evidence satisfies the requirement. Follow-up challenges MUST remain bound to the original boundary-computed action and MUST NOT derive that action from presenter input.¶
A declaration or challenge authorizes nothing, reserves nothing, and promises no execution. A satisfied challenge still proceeds through native verification, exact-action correspondence, AUTHORIZED, stable replay identity, and atomic consumption or reservation. MATCH and SATISFIED also apply when the relying party selects CAID and AEC. This document intentionally defines no new manifest object, challenge object, well-known URI, HTTP status code, or media type.¶
WIMSE workload credentials and the WIMSE HTTP Message Signatures profile [WIMSE-HTTP] can provide end-to-end workload authentication and message integrity for the request components covered by the validated signature, including a body protected by a validated content digest. HTTP Message Signatures [RFC9421] provide the underlying component-signing mechanism.¶
AEB consumes those results; it does not redefine them. A validated WIMSE request can establish which workload possessed the protected key and that covered message components were not modified undetectably. It does not by itself establish CAID MATCH, AEC SATISFIED, named-human authorization, local AUTHORIZED, one-time consumption, or execution.¶
The WIMSE AI Identity Management System (AIMS)
[WIMSE-AIMS] profiles existing identity and
authorization standards for agent workloads, including OAuth and
Transaction Tokens. The individual
draft-munoz-wimse-authorization-evidence submission
[MUNOZ-WIMSE-EVIDENCE] describes an adjacent signed-
evidence composition. AEB begins after the selected native identity
and authorization path has produced the inputs enforced at the effect
boundary. It does not replace their issuance, verification, mapping,
or authorization semantics.¶
PEDIGREE [PEDIGREE] describes native identity and delegation-chain evidence. The AEB result records whether the relying party's stated delegation requirement was satisfied by the mapped evidence. It does not reinterpret, re-derive, or override the delegation protocol's native decision. In particular, a PEDIGREE completion block is post-effect evidence and MUST NOT fill a pre-action authorization role.¶
Headers, routing metadata, forwarded identity, trace context, or other values that an intermediary can add, remove, or mutate outside the validated end-to-end integrity coverage MUST NOT be load-bearing authorization evidence. They MAY be used for routing or diagnostics. If such a value affects the protected consequence, the boundary MUST derive it independently or require it to be covered by accepted native integrity and the observed action's material binding.¶
The AuthZEN Authorization API [AUTHZEN-API] defines the PDP request and decision interface. COAZ [AUTHZEN-COAZ] defines how an incoming protocol operation is projected into the AuthZEN subject, action, resource, and context model. COAZ-MCP [AUTHZEN-COAZ-MCP] applies that mapping to MCP operations. Those specifications remain authoritative for operation-to-SARC mapping, PDP evaluation, and PEP enforcement.¶
AEB does not replace COAZ mapping with CAID and does not require a second PDP. The effect-owning PEP can record AUTHORIZED when it accepts an AuthZEN permit for the exact operation under the selected COAZ profile. CAID is needed only if the boundary must compare that operation with an independently encoded provider action. AEC is needed only if local policy adds multiple evidence roles beyond the native decision.¶
OAuth access tokens, Rich Authorization Requests, Transaction Tokens, and related artifacts remain native OAuth inputs. OAuth authorization servers retain their OAuth roles; a Transaction Token Service retains Transaction Token issuance; and each accepting workload or resource retains its native authorization and enforcement decision. Their token, proof-of-possession, audience, and transaction semantics are not redefined by AEB. AEB applies only the downstream custody and provider-effect lifecycle selected by the effect-owning relying party.¶
AP2 mandates [AP2] likewise retain AP2's native verification, checkout, transaction-linkage, issuer, holder, and payment semantics. An AEB implementation can consume an AP2 result and control one covered provider entry without converting the mandate into an AEB token or claiming AP2 interoperability.¶
Attested per-action tokens, including artifacts described by a deployment as OASNT-like, remain native evidence formats. AEB does not assign that descriptive label a token type, claim set, registry entry, or trust meaning. The selected native verifier determines what the token proves and exposes its integrity-protected action commitment, issuer, audience, validity, freshness, status, and bounded result to the AEB adapter.¶
SCITT Permit records defined by [MUNOZ-PERMIT] likewise remain native pre-execution decision evidence. AEB does not reserialize a Permit or convert it into an AEB receipt. It verifies the selected Permit revision through its native adapter, maps its protected material action only through a pinned CAID profile, and assigns it only to evidence roles permitted by the relying party's AEC requirement.¶
A native format's valid signature proves only the statement and signer semantics that format defines. It does not, without an additional accepted profile and evidence, prove that a natural person operated the workload, understood the action, held authority, or performed a particular approval ceremony.¶
An AEB adapter compiles the result of a native verifier into the inputs needed by the AEB processing model. The native artifact, verifier, trust model, and result remain authoritative for their own semantics. Compilation MUST NOT convert a native result into an AEB credential or permit, and an AEB result MUST NOT overwrite a native result.¶
The compilation target is the ordered AEB decision and lifecycle vocabulary: native verification, exact-action correspondence, authorization, stable replay identity, atomic reservation or consumption, provider entry, outcome classification, and authenticated reconciliation. CAID matching and AEC satisfaction are included only when the relying party selects the corresponding cross-format or multi-leg stage. A successful compile establishes only that the native result can be evaluated at those interfaces. It does not establish that the action is authorized, executed, safe, lawful, or true.¶
Before compilation, the relying party MUST pin:¶
Presented data MAY select among already pinned native variants only where the native protocol defines that selection and the relying party enables it. Presented data MUST NOT add or change a trust root, verifier, mapping, evidence role, material-field rule, or replay scope.¶
A verifier implementation identifier and digest are relying-party- selected configuration metadata. They do not prove that a measured runtime loaded or executed those bytes. A compile result MUST keep runtime measurement unestablished unless a separate accepted native attestation proves it.¶
An adapter exposes verifyNative, which verifies the artifact
under the pinned native rules and returns the integrity-protected
native result and exact operation binding. When the boundary performs
a cross-format join, the adapter also exposes the logically separate
mapAction operation, which maps only a VERIFIED native result
to the relying party's expected action under the pinned mapping
profile.¶
Each selected operation MUST be deterministic for the supplied bytes and pins. It MUST NOT perform a network request, consult ambient credentials or trust stores, read mutable global state, or accept a caller-supplied verification verdict. Required current status and time MUST be explicit relying-party inputs.¶
The boundary MUST supply detached, recursively immutable copies of the native artifact, expected action, trust inputs, status inputs, adapter configuration, and mapping profile. An adapter MUST NOT change a pinned input between native verification and action mapping.¶
For each native artifact, the compiler MUST return a closed result that contains:¶
The compile result is typed verifier output. It is not a bearer token, permit, receipt, or proof of execution. A deployment MAY serialize it for diagnostics or evidence transport, but that serialization MUST NOT become reusable authority.¶
A native profile MAY expose actor, acting-for principal, target, declared purpose, audience, constraints, validity, or native nonclaims only when its native verifier and pinned mapping establish those values. The generic compiler MUST NOT infer them from a subject identifier, policy decision, action label, natural-language field, or trace metadata merely to fill a common shape.¶
A caller-supplied local-policy decision MAY be reported as an explicit input, but it MUST NOT establish local authorization. Authorization, reservation or consumption, provider entry, outcome, and reconciliation remain unestablished until the component that owns each transition evaluates and records it.¶
The adapter MUST enumerate every field exposed by the native verifier that the selected mapping does not carry into the target action or accepted evidence role. Each omission MUST be classified as material, non-material, or unknown under relying-party-pinned rules, with a stable field path and declared basis.¶
An omitted material or unknown field makes exact-action matching INDETERMINATE. That leg MUST NOT report equivalence, MATCH, SATISFIED, or AUTHORIZED. Renaming, moving, defaulting, unit-converting, rounding, truncating, or combining a material field is a transformation and requires a pinned deterministic rule. Natural-language similarity, an agent assertion, or a shared trace identifier is not such a rule.¶
The compiler MAY retain a native mapper's raw relation, CAID, and normalized-action digest for diagnostics, but MUST label them as raw native output. They MUST NOT appear as the compiler-effective relation after material or unknown loss. The effective CAID and normalized- action digest are absent in that case.¶
If two compiled legs produce one CAID but different normalized- action digests, the boundary MUST refuse the join. CAID remains a typed content identifier. It is not an authorization claim or a general declaration that two source formats have identical semantics.¶
Every accepted authorization-bearing native result MUST expose a stable native replay unit derived from the verified native authority. The replay unit MUST NOT include an AEB wrapper digest, AEB operation identifier, consumption nonce, caller retry identifier, or other value whose change would make the same native authority spendable again.¶
The evaluator MUST probe the adapter with a second deterministic wrapper reference. If the replay unit changes while the verified native authority does not, the result is INDETERMINATE. If two distinct verified native artifacts from one adapter collapse onto one replay unit without the native profile defining that equivalence, the result is INDETERMINATE. A replay-unit value does not prove that reservation or consumption occurred.¶
A deployment MUST state whether the AEB boundary controls the credential or other capability that reaches the effecting provider, which provider-entry paths it mediates, and every direct, administrator, break-glass, alternate-protocol, queued, or system-of- record path that bypasses it. An observe-only adapter or an adapter placed beside a write path MUST NOT be described as consequence admission or complete mediation.¶
The compile result MAY record provider-attempt and reconciliation bindings only after the corresponding AEB transitions occur. A policy allow, access token, message signature, transparency receipt, action record, audit record, or native permit MUST NOT be relabeled as proof that provider entry, commitment, or an external effect occurred.¶
A native compilation profile MUST publish exact source locks, at least one positive vector containing the original native bytes, and a condition-removed control for every negative vector. Reports MUST keep native verification, mapping, AEC, local policy, reservation, provider outcome, and reconciliation results separate.¶
The profile MUST include hostile vectors for material-field omission and substitution, mapping-pin change, stale or unavailable status, wrapper replay, alternate-path bypass, refusal-time consumption, concurrent admission, timeout after provider entry, blind retry, and reconciliation binding mismatch. It MUST state every native semantic that could not be compiled without invention.¶
A profile that claims a direct native authorization path MUST show the exact native operation binding and stable replay identity without inserting a second PDP. A profile that joins a separately encoded provider action MUST exercise the selected CAID mapping, including a material-field substitution. A profile that adds multiple evidence roles MUST exercise the selected AEC requirement. Each report MUST say which conditional stages were used and why.¶
A generic AEB compiler conformance claim requires at least two materially unrelated native profiles to reach the same AEB lifecycle without changing their native wire formats or result semantics. A same-team runner is reference evidence, not an independent implementation. Matching a finite vector set does not establish complete mediation, production deployment, or provider truth.¶
An implementation conforms to AEB only if every protected invocation follows the ordered processing model in Section 5 and fails closed on every missing or ambiguous required transition. A deployment MUST state whether CAID or AEC is selected and MUST document:¶
An implementation placed beside a write path is not complete mediation. A deployment MUST NOT claim complete mediation unless the protected system rejects all material alternate paths or subjects them to an equivalent boundary. Observe-only operation MAY be useful during deployment, but it MUST NOT be described as enforcement.¶
Cross-binding. An attacker can splice a valid permit, approval, credential, or receipt for action A into a request for action B. Native verification before mapping, executor-owned action construction, and exact correspondence between the authorized operation and provider entry are required defenses. A cross-format join also requires exact CAID matching. A multi-leg requirement also requires a relying-party-pinned AEC evaluation. Omitting a stage that the selected profile requires reopens the attack.¶
Mutable context. Intermediary-added headers and agent annotations are convenient but are not trustworthy merely because they arrived on an authenticated hop. Every load-bearing field needs accepted end-to-end integrity coverage or independent derivation at the effect boundary.¶
Time of check and time of use. The action passed to the executor must be the frozen action that was verified, matched, satisfied, authorized, and consumed or reserved. Mutable aliases, provider defaults, exchange rates, destinations, branch heads, and policy epochs can change a consequence after approval; profiles must bind or revalidate them as material fields.¶
Replay and distributed state. Process-local caches are insufficient where replicas can invoke the same effect. Replay, consumption, reservation, and operation ownership state must be durable, atomic, and shared across every boundary instance that can reach the protected executor.¶
Freshness and revocation. Expiration, nonce checks, credential status, authority status, and policy epoch are separate checks. A fresh message does not make a revoked credential valid, and a current credential does not make old per-action evidence fresh.¶
Indeterminate effects. Retrying after a timeout can duplicate a payment, mutation, disclosure, or physical action. An invocation that might have reached the provider consumes the operation's retry right until authenticated reconciliation resolves the exact outcome. Caller assurances and unauthenticated webhooks do not resolve it.¶
Signature overclaiming. A cryptographic signature can establish control of a key and integrity of covered content under a selected verification profile. It does not inherently identify a human, prove human operation, prove comprehension, establish legal authority, or prove execution.¶
Boundary bypass. A correct AEB implementation does not protect direct database credentials, alternate APIs, shell access, administrator consoles, side channels, or actuator paths that bypass it. Deployment topology and credential placement are security properties, not implementation details.¶
Action objects and evidence can expose identities, destinations, resources, policy choices, commercial relationships, and sensitive operational timing. Deployments SHOULD minimize the evidence passed to the executor and retained in portable records, use opaque high-entropy references where appropriate, and avoid treating a plain digest of low-entropy personal data as anonymization.¶
Reconciliation queries can disclose that an operation is disputed or uncertain. They SHOULD be authenticated, authorized, rate-limited, and limited to the exact operation. AEB does not require public disclosure of native evidence or local policy.¶
CAID [CAID] owns typed material-action identity and exact, relying-party-pinned cross-format mapping. AEB invokes CAID after native verification only when independently encoded representations must be joined. It does not extend CAID with trust semantics.¶
AEC [AEC] owns heterogeneous evidence composition and the SATISFIED or UNSATISFIED result under a relying-party requirement. AEB invokes AEC only when local policy requires multiple evidence legs, then preserves the separate authorization and effect-lifecycle decisions. The earlier Action Evidence Graph series [AEG] is replaced by AEC; an implementation following an older citation MUST NOT treat the superseded series as a second composition contract.¶
AIMS, OAuth, AuthZEN, COAZ, and AP2 own their respective identity, delegation, authorization, protocol mapping, mandate, and native enforcement semantics. AEB is a post-permit consequence-admission lifecycle at a covered effect boundary. It does not create a parallel identity system, authorization server, PDP, mandate, or universal token.¶
Authorization Receipts [RECEIPTS] define one native action-bound organizational approval artifact and its receipt-specific consumption semantics. AEB does not make that format mandatory and does not generalize every native artifact into an EMILIA receipt.¶
Static declarations and dynamic evidence challenges remain distinct protocol surfaces. A manifest can advertise discovery metadata, while an Authorization Evidence Challenge can carry the live, action-bound refusal and acquisition instructions. AEB owns the executor lifecycle in which those inputs are evaluated; it does not absorb or replace their wire formats.¶
Qualification, revocation, remedy, and action-to-outcome continuity artifacts are optional native inputs or downstream records. They retain their own semantics. AEB composes them only through pinned verification, exact-action binding, local policy, durable custody, and authenticated reconciliation.¶
A refusal MAY be represented by an action-bound signed refusal statement. The refusal artifact records what the boundary refused and why; it MUST NOT be interpreted as proof that every bypass path was mediated, that delivery to a requester occurred, or that a later action was refused.¶
This document has no IANA actions. In particular, it creates no registry for native evidence types, lifecycle labels, verifier adapters, action mappings, or policy identifiers.¶
This revision positions AEB explicitly after native identity and authorization systems. It makes CAID conditional on a cross-format join and AEC conditional on a multi-leg evidence requirement. It states that an effect-owning PEP can accept a native authorization result without a second PDP; AuthZEN and COAZ retain ownership of SARC mapping, PDP evaluation, and PEP enforcement. It distinguishes an authorized MCP or API request from a downstream provider effect and makes the post-permit sequence explicit: stable replay identity, durable consume or reserve, provider entry, terminal or indeterminate outcome, and authenticated reconciliation without blind retry. It updates the former KLRC reference to the WIMSE AIMS working-group document and adds informative AuthZEN, COAZ, COAZ-MCP, and AP2 references. The revision creates no credential, permit, receipt, registry, policy language, PDP, or universal token.¶
The Apache-2.0 reference implementation provides relying-party-pinned
adapter and mapping registries, multi-leg CAID joins, the boundary terms
defined above, current-status verification, signed configuration-bound
evaluation records, durable ownership-fenced one-time consumption,
execution reservation and reconciliation, and signed refusal statements.
It also exposes a closed native-compiler report over the adapter contract,
an AuthZEN-derived local PEP-observation profile, a source-pinned OAuth
Transaction Authorization Challenge profile
[OAUTH-TXN-CHALLENGE], a strict request-only profile over
WPT-02 [WIMSE-WPT] and Transaction Tokens -11
[OAUTH-TXN-TOKENS], and a WIMSE R10 compatibility matrix.
All three paths pass locally. The AuthZEN-derived path verifies an
EMILIA-signed local
PEP observation, not an artifact defined or signed by AuthZEN. It
therefore does not count toward the two-external-native-profile gate.
OAuth transaction challenge and WPT plus Transaction Tokens are the two
direct external-native candidates. Their mappings have not been reviewed
by the native protocol owners, the published profiles still need an
audited match against every required hostile vector and paired control,
and their OAuth adjacency requires an explicit protocol-diversity
judgment before the generic gate can close.
The result is not an independent implementation or an adoption claim.
The informative EP-FIELD-ORIGIN-v0.1 profile is evaluated before
admission in the reference Gate. Its Gap 6 implementation profile has 14
deterministic cases, including disallowed field origins, unknown origin,
profile substitution, an unpinned transformation, and the positive case
in which untrusted content supplies only a bounded memo field.
Conformance vectors and adversarial tests cover selected reference paths;
the full conformance set above remains future conformance work and is not
established by this revision.
These same-team artifacts are not an independent implementation and do
not prove that a deployment mediates every effect path.¶
External review sharpened the boundaries between workload and message integrity, per-action authorization evidence, credential status, human operation, and executor-owned effect control. Those distinctions are load-bearing in this document. Acknowledgment does not imply endorsement.¶