Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)
draft-schrock-ep-authorization-evidence-chain-05

Network Working Group                                         I. Schrock
Internet-Draft                                     EMILIA Protocol, Inc.
Intended status: Informational                             3 August 2026
Expires: 4 February 2027

  Authorization Evidence Chains: Composing Heterogeneous Agent-Action
                           Evidence (EP-AEC)
            draft-schrock-ep-authorization-evidence-chain-05

Abstract

   Consequential agent actions can produce heterogeneous identity,
   delegation, policy, permit, approval, transparency, capability, and
   execution artifacts.  Each artifact can verify under its own
   specification while still referring to a different action, filling a
   different evidentiary role, or failing a relying party's freshness,
   status, or inter-artifact binding requirement.  This document defines
   the Authorization Evidence Chain (EP-AEC): a transport-agnostic
   composition object and a fail-closed evaluation algorithm that
   preserves native verification, establishes exact material-action
   matching, and evaluates a relying-party-pinned evidence requirement.

   AEC produces SATISFIED or UNSATISFIED and a replayable evaluation
   record.  SATISFIED means only that the presented evidence filled the
   relying party's named evidence requirement at the stated verification
   time.  It is not a universal authorization decision, a policy
   language for the protected application, or proof of execution or
   outcome.  The executor makes the separate local AUTHORIZED decision
   and controls consumption, invocation, and effect handling.
   Qualification evidence can fill a named evidence role but cannot
   authorize an action by itself.  AEC introduces no new component
   receipt type and does not replace any native verifier.

Status of This Memo

   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."

Schrock                  Expires 4 February 2027                [Page 1]
Internet-Draft        Authorization Evidence Chains          August 2026

   This Internet-Draft will expire on 4 February 2027.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The Authorization Evidence Chain Object . . . . . . . . . . .   4
   4.  The Relying-Party Evidence Requirement  . . . . . . . . . . .   6
   5.  Relying-Party Acceptance Inputs . . . . . . . . . . . . . . .   7
   6.  Native Verification and Normalized Facts  . . . . . . . . . .   8
   7.  Material-Action Matching  . . . . . . . . . . . . . . . . . .   9
   8.  Requirement Expressions . . . . . . . . . . . . . . . . . . .   9
   9.  Verification Algorithm  . . . . . . . . . . . . . . . . . . .  10
   10. Evidence Evaluation Replay  . . . . . . . . . . . . . . . . .  11
   11. Human-Authorization Components  . . . . . . . . . . . . . . .  12
   12. Bounded-Capability Operation Components . . . . . . . . . . .  12
   13. Position in the Effect-Boundary Lifecycle . . . . . . . . . .  13
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   16. Relationship to Other Work  . . . . . . . . . . . . . . . . .  15
   17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   18. Changes in -05  . . . . . . . . . . . . . . . . . . . . . . .  16
   19. Implementation Status . . . . . . . . . . . . . . . . . . . .  16
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     20.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

Schrock                  Expires 4 February 2027                [Page 2]
Internet-Draft        Authorization Evidence Chains          August 2026

1.  Introduction

   One consequential action can produce several independently useful
   artifacts: a workload credential, a delegation record, a policy
   permit, a named-human authorization receipt, a quorum, a bounded-
   capability operation record, or a transparency receipt.  These
   artifacts answer different questions.  A relying party may require
   several of them for one action.

   Native validity is not sufficient for composition.  A valid permit
   for action A and a valid approval for action B do not jointly
   authorize either action.  Likewise, two valid artifacts can still be
   inadequate if the relying party required a fresher approval, a
   checked revocation status, or a byte-backed relation showing that one
   artifact explicitly references another.

   EP-AEC provides the thin composition layer.  It dispatches artifacts
   to their native verifiers, maps only integrity-protected native
   action commitments to the relying party's expected material action,
   evaluates an evidence requirement owned by the relying party, and
   records the exact inputs to that evidence decision.  It does not
   decide whether the protected application should act.

1.1.  Scope and Non-Goals

   This document defines:

   *  the EP-AEC-v1 composition object;

   *  the EP-AEC-REQUIREMENT-v1 relying-party evidence requirement;

   *  a verifier-result contract that keeps native verification separate
      from material-action mapping;

   *  a fail-closed SATISFIED or UNSATISFIED evaluation; and

   *  the EP-AEC-REPLAY-v1 evaluation record and replay digest.

   This document does not define a universal evidence taxonomy, a
   general authorization policy language, a component receipt format, an
   application allow or deny decision, a signed reliance-result format,
   a transparency service, or an execution state machine.  It does not
   require a graph wire format or make presenter-asserted graph edges
   authoritative.

Schrock                  Expires 4 February 2027                [Page 3]
Internet-Draft        Authorization Evidence Chains          August 2026

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   BCP 14 is indexed by the RFC Editor at [BCP14].

   Native verifier  A verifier selected by the relying party for one
      artifact format and revision.  It checks that format's syntax,
      signatures, issuer, audience, validity, and format-specific
      semantics under pinned trust inputs.

   VERIFIED  The native verifier accepted an artifact under the selected
      native profile.  This state alone says nothing about whether the
      artifact denotes the expected material action.

   MATCH  A VERIFIED artifact's integrity-protected native action
      commitment denotes the relying party's expected material action by
      direct exact digest equality or by an exact, relying-party-pinned
      CAID mapping profile.

   SATISFIED  Eligible evidence filled the relying party's evidence
      requirement at the explicit verification time.

   AUTHORIZED  A separate local application decision permitting an
      invocation.  AEC does not produce this state.

   Evidence digest  The string "sha256:" followed by the lowercase
      hexadecimal SHA-256 digest of an artifact's JCS [RFC8785]
      serialization.

   Normalized evidence fact  A verifier-produced, bounded record of
      native validity, material-action mapping, time and status checks,
      and byte-backed bindings for one component.  It is not supplied by
      the presenter.

3.  The Authorization Evidence Chain Object

Schrock                  Expires 4 February 2027                [Page 4]
Internet-Draft        Authorization Evidence Chains          August 2026

   {
     "@version": "EP-AEC-v1",
     "action": { "...": "Action Object" },
     "action_digest": "sha256:<hex>",
     "action_caid": "caid:1:<action-type>:<suite>:<digest-b64url>",
     "components": [
       {
         "type": "ep-quorum",
         "label": "two-person human authorization",
         "evidence_digest": "sha256:<hex>",
         "evidence": { "...": "native artifact" }
       },
       {
         "type": "policy-permit",
         "evidence": { "...": "native artifact" }
       }
     ],
     "requirement": "ep-quorum AND policy-permit"
   }

   *  @version (string, REQUIRED) MUST equal EP-AEC-v1.

   *  action (object, REQUIRED) is the closed Action Object to which the
      evaluation is joined.

   *  action_digest (string, OPTIONAL) is descriptive.  When present, it
      MUST equal the verifier's recomputation over action.

   *  action_caid (string, OPTIONAL) is descriptive.  It MUST NOT
      establish its own mapping or trust.  When the relying party
      requires a CAID, the verifier recomputes or independently obtains
      the expected CAID and compares it as specified in Section 7.

   *  components (array, REQUIRED and non-empty) contains type (string),
      evidence (JSON value suitable for the native format), and optional
      label and evidence_digest strings.  A label is display-only.  When
      an evidence digest is present, the verifier MUST recompute and
      compare it before native verification.

   *  requirement (string, OPTIONAL) is a presenter-supplied
      description.  It MUST NOT become the relying party's sufficiency
      bar and MUST NOT produce SATISFIED.

   The chain is a bundle, not an authority-bearing graph.  Component
   order is preserved for reporting, but order confers no semantics.
   All credited relations between components come from integrity-
   protected native bytes exposed by a trusted native verifier, never
   from labels, ordering, or presenter-supplied edges.

Schrock                  Expires 4 February 2027                [Page 5]
Internet-Draft        Authorization Evidence Chains          August 2026

4.  The Relying-Party Evidence Requirement

   Before returning SATISFIED, a verifier MUST receive an EP-AEC-
   REQUIREMENT-v1 object from relying-party-controlled configuration.
   The chain document cannot supply or weaken it.

   {
     "@version": "EP-AEC-REQUIREMENT-v1",
     "requirement_id": "treasury-wire-evidence@7",
     "purpose": "pre-execution evidence check",
     "expression": "ep-quorum AND policy-permit",
     "freshness_sec": {
       "ep-quorum": 300,
       "policy-permit": 600
     },
     "status_required": ["ep-quorum"],
     "role_constraints": [
       {
         "type": "distinct-subject-quorum",
         "component_type": "ep-human-authorization",
         "threshold": 2,
         "subject_id_source": "native-verifier"
       }
     ],
     "required_bindings": [
       {
         "from_type": "policy-permit",
         "relation": "permits",
         "to_type": "ep-quorum"
       }
     ]
   }

   *  @version MUST equal EP-AEC-REQUIREMENT-v1.

   *  requirement_id is a relying-party identifier for the exact
      evidence requirement revision.  It carries no authority by itself.

   *  purpose is descriptive and MUST NOT alter expression evaluation.

   *  expression is REQUIRED and follows Section 8.

   *  freshness_sec is an OPTIONAL map from component type to a non-
      negative maximum age in seconds.

   *  status_required is an OPTIONAL array of component types for which
      a fresh authenticated status result is required.

Schrock                  Expires 4 February 2027                [Page 6]
Internet-Draft        Authorization Evidence Chains          August 2026

   *  role_constraints is an OPTIONAL array of closed evidence
      constraints.  This revision defines only distinct-subject-quorum.
      Its component_type names an evidence role, threshold is an integer
      greater than one, and subject_id_source MUST equal native-
      verifier.  A verifier counts distinct subjects only from
      integrity-protected native subject identifiers returned by
      eligible native verifiers.  Presenter labels, signer-key
      encodings, and unverified subject claims MUST NOT be counted.

   *  required_bindings is an OPTIONAL array of from_type, relation, and
      to_type triples.  Each triple requires at least one eligible
      source component whose native verified bytes bind, under that
      relation, the evidence digest of an eligible target component of
      the named type.

   The verifier MUST compute the requirement profile digest over the JCS
   serialization of the complete requirement object.  The requirement
   object controls evidence sufficiency only.  Application rules about
   amounts, destinations, operator permissions, legal authority, risk
   acceptance, or whether to execute remain in the separate local
   authorization policy.

   Initiator exclusion, executor exclusion, durable one-time
   consumption, resource ceilings, and whether to execute are boundary
   constraints rather than evidence-sufficiency constraints.  They are
   defined and enforced by the Action Evidence Boundary [EP-AEB].  AEC
   MUST NOT report them as satisfied merely because an evidence
   component asserts them.

5.  Relying-Party Acceptance Inputs

   Internal agreement among presenter-supplied artifacts cannot satisfy
   a relying party.  The verifier MUST receive these values from trusted
   configuration or from the protected boundary that is about to act:

   *  the EP-AEC-REQUIREMENT-v1 object;

   *  the expected Action Object or its independently computed canonical
      action digest;

   *  an expected CAID and mapping profiles when cross-format action
      mapping is used;

   *  an explicit verification time;

   *  the native verifier revisions, trust anchors, audiences, freshness
      inputs, and status sources selected for each component type; and

Schrock                  Expires 4 February 2027                [Page 7]
Internet-Draft        Authorization Evidence Chains          August 2026

   *  documented resource limits for parsing, nesting, component count,
      expression size, and verifier execution.

   These values MUST NOT be taken from the presented chain or from an
   untrusted caller.  If any required input is absent, malformed,
   ambiguous, or outside its configured validity, the result is
   UNSATISFIED.

6.  Native Verification and Normalized Facts

   AEC does not reinterpret a native signature or token.  For each
   component, a relying-party-selected native verifier first returns a
   bounded internal result containing:

   *  native validity and a machine-readable failure reason;

   *  the integrity-protected native action commitment, if any;

   *  the protected issuance and expiration instants needed by the
      selected freshness check;

   *  the protected issuer, audience, and format revision relevant to
      the selected native profile;

   *  an authenticated status result and status-snapshot digest when
      status checking is required; and

   *  zero or more relation and target-evidence-digest bindings
      extracted from integrity-protected native fields.

   A component reaches VERIFIED only when its native verifier succeeds.
   AEC MUST NOT accept a presenter's verified Boolean, normalized fact,
   mapping result, key, trust anchor, status assertion, or relation as a
   substitute for native verification.

   A deployment in which a protected boundary performs native
   verification before calling the AEC evaluator MAY pass the verifier
   results internally instead of repeating the cryptographic work.  Such
   results MUST be integrity-bound inside the same trust boundary to the
   exact evidence digest, native verifier profile digest, trust
   snapshot, and verification time.  Serialized results received from
   the presenter are evidence artifacts of their own and require a
   native verifier; they are not trusted internal results.

Schrock                  Expires 4 February 2027                [Page 8]
Internet-Draft        Authorization Evidence Chains          August 2026

7.  Material-Action Matching

   Native verification and material-action matching are distinct and
   ordered.  Mapping MUST NOT inspect unverified claims as authoritative
   input.

   1.  The boundary computes the expected action digest from the frozen
       action it is actually preparing to perform.

   2.  The native verifier verifies the component and exposes only its
       integrity-protected native action commitment.

   3.  If that commitment uses the same action representation and digest
       algorithm, exact digest equality establishes MATCH.

   4.  Otherwise, a relying-party-pinned Action-Mapping Profile from
       [CAID] projects the verified native payload to the expected CAID
       action type.  Only the CAID verdict EQUIVALENT_UNDER_PROFILE
       establishes MATCH.

   NOT_EQUIVALENT, INDETERMINATE, an unknown mapping revision, a lossy
   projection, a presenter-selected profile, or a mismatch between the
   projected CAID and the expected CAID is not MATCH and MUST make that
   component ineligible.  CAID carries content identity, not trust or
   authorization semantics.

8.  Requirement Expressions

   The expression grammar uses ABNF and its core rules as defined by
   [RFC5234]:

   expr     = term *(WS operator WS term)
   term     = ident / "(" WS expr WS ")"
   operator = "AND" / "OR" / "&&" / "||"
   ident    = 1*(ALPHA / DIGIT / "." / ":" / "-" / "_")
   WS       = *(SP / HTAB / CR / LF)

   An identifier matches a component type with at least one eligible
   component.  An unknown identifier evaluates to false.
   Implementations MUST use a bounded parser and MUST NOT use a general-
   purpose evaluator.  AND and OR have equal binding strength and are
   evaluated strictly from left to right.  Parentheses are the only
   precedence mechanism.

   This expression deliberately answers only which evidence roles are
   present.  It has no variables for action parameters, principals,
   entitlements, business risk, or effect state.  Those belong to native
   artifact verification, CAID mapping, or local authorization.

Schrock                  Expires 4 February 2027                [Page 9]
Internet-Draft        Authorization Evidence Chains          August 2026

9.  Verification Algorithm

   Given chain C and the acceptance inputs in Section 5, a verifier MUST
   proceed fail-closed:

   1.  Strictly parse C as I-JSON [RFC7493] and enforce all configured
       resource limits.  Reject duplicate member names, non-integer
       numbers, malformed Unicode, cycles in an in-memory object, and
       unsupported versions.

   2.  Compute the canonical action digest over C.action.  Compare it
       with the executor-owned expected action digest.  If
       C.action_digest is present, compare it too.  Any mismatch yields
       UNSATISFIED.

   3.  Validate and digest the relying-party requirement.  If the only
       available requirement came from C, yield UNSATISFIED.

   4.  For each component in array order:

       a.  Compute its evidence digest.  If a presented evidence digest
           exists and differs, mark the component ineligible.

       b.  Invoke the selected native verifier or consume a trusted
           internal verifier result as constrained by Section 6.
           Exceptions and unknown verifier types make the component
           ineligible.

       c.  Only after native VERIFIED, establish material-action MATCH
           under Section 7.  A different or indeterminate action makes
           the component ineligible.

       d.  If the requirement sets a freshness bound for the component
           type, require protected issuance time, verification time
           within the native validity window, and age not exceeding the
           bound.  Future-issued, expired, missing, or malformed times
           make the component ineligible.

       e.  If status is required for the component type, require an
           authenticated, sufficiently fresh status snapshot under the
           selected native profile.  Revoked, unknown, stale, or
           unauthenticated status makes the component ineligible.

       f.  Record a normalized fact including component index, type,
           evidence digest, native verifier profile digest, native
           validity, mapping verdict, freshness and status results, and
           only the byte-backed bindings returned by the native
           verifier.

Schrock                  Expires 4 February 2027               [Page 10]
Internet-Draft        Authorization Evidence Chains          August 2026

   5.  Construct the satisfied type set from eligible components only
       and evaluate the relying-party expression.  Evaluate every
       role_constraints entry over eligible normalized facts only.  A
       failed or indeterminate role constraint yields UNSATISFIED.

   6.  For every required binding, require an eligible source and target
       pair with matching types and a source native fact whose named
       relation binds the target's exact evidence digest.  A label,
       component order, equal action digest, or presenter's relation
       claim does not satisfy a required binding.

   7.  Return SATISFIED only if the expression is true, every required
       binding exists, and every mandatory acceptance check succeeded.
       Otherwise return UNSATISFIED.

   8.  Produce the replay record in Section 10.  Any unexpected error at
       any step yields UNSATISFIED and a bounded reason; it MUST NOT
       yield a partial success.

   The result MUST carry satisfied as a Boolean and SHOULD carry bounded
   per-component reason codes.  An implementation may retain a legacy
   allow alias, but that alias MUST equal satisfied and MUST NOT be
   interpreted as local AUTHORIZED.

10.  Evidence Evaluation Replay

   An evaluator MUST be able to emit an EP-AEC-REPLAY-v1 record.  The
   replay record is an evaluation output, not a presenter input:

   {
     "@version": "EP-AEC-REPLAY-v1",
     "aec_digest": "sha256:<hex>",
     "expected_action_digest": "sha256:<hex>",
     "expected_caid": "caid:1:<action-type>:<suite>:<digest-b64url>",
     "requirement_profile_digest": "sha256:<hex>",
     "verification_time": "2026-07-27T17:00:00Z",
     "facts": [ { "...": "normalized evidence fact" } ],
     "satisfied": true,
     "reasons": []
   }

   The aec_digest is the evidence digest of the complete EP-AEC-v1
   object.  Facts remain in component array order.  Object members
   inside each fact use JCS ordering.  The replay digest is the evidence
   digest of the complete EP-AEC-REPLAY-v1 record.

Schrock                  Expires 4 February 2027               [Page 11]
Internet-Draft        Authorization Evidence Chains          August 2026

   Given the same AEC object, expected action inputs, requirement
   profile, explicit verification time, normalized native facts, and
   algorithm revision, implementations MUST compute the same replay
   digest and SATISFIED result.  Native verification can depend on trust
   snapshots or status services; therefore the replay record MUST bind
   the selected verifier-profile and status-snapshot digests needed to
   identify those inputs.  A replay record without the underlying
   evidence and identified trust snapshots can identify a decision but
   cannot independently prove that every recorded native fact was true.

   The replay digest is not a signature, authorization, transparency
   receipt, or current-status proof.  Another format MAY sign or log it.
   This document intentionally defines no signed reliance-result
   envelope and no legal meaning for a SATISFIED result.

11.  Human-Authorization Components

   AEC does not infer that a generic operator signature, credential,
   policy decision, or attested workload represents a named-human
   approval ceremony.  A relying party that needs an EMILIA human
   authorization or quorum requires ep-receipt or ep-quorum explicitly.

   The ep-receipt built-in MUST accept only a Trust Receipt under a
   relying-party profile that pins the approver directory, accepted key
   class, WebAuthn RP ID and signed-origin allowlist where required,
   policy hash, log key, maximum evidence age, verification time, and
   fresh registry snapshot as specified by [EP-RECEIPTS].  A bare
   operator envelope is not an ep-receipt human leg.

   The ep-quorum built-in MUST compare the presented quorum policy with
   the relying-party-pinned policy and enforce the selected approver,
   role, distinctness, origin, ordering, and freshness rules of
   [EP-QUORUM].  A safety-critical profile requiring human separation
   MUST require at least two distinct humans.  A valid quorum under
   presenter-selected keys or a weaker presenter-selected policy is
   ineligible.

   Credential validity and human operation remain distinct.  A valid
   credential identifies a key holder under its native profile; it does
   not establish that a human operated an agent for this action,
   reviewed the material fields, or held legal authority.

12.  Bounded-Capability Operation Components

   A static bounded-capability receipt authorizes capability issuance
   and MUST NOT be treated as bound to every later exercise merely
   because the proposed action falls within its scope.

Schrock                  Expires 4 February 2027               [Page 12]
Internet-Draft        Authorization Evidence Chains          August 2026

   A bounded-capability-operation component is eligible only when its
   native verified operation record binds the exact action and the
   native verifier validates the referenced capability, issuance
   authorization, scope result, and operation record.  AEC does not
   query or reserve current budget.  A capability component MUST NOT
   satisfy ep-receipt, ep-quorum, or another human role.

13.  Position in the Effect-Boundary Lifecycle

   AEC occupies one deliberately narrow transition in the effect-
   boundary lifecycle described by [EP-AEB]:

   native VERIFIED
     -> material-action MATCH
     -> AEC SATISFIED
     -> local AUTHORIZED
     -> atomic CONSUMED or RESERVED
     -> INVOKED
     -> EXECUTED, FAILED, or INDETERMINATE

   AEC can orchestrate native verification and mapping itself or consume
   trusted internal results from the same protected boundary.  In both
   arrangements, VERIFIED precedes MATCH, and both precede SATISFIED.
   AEC MUST NOT collapse SATISFIED into AUTHORIZED, consume an
   authorization, invoke an effect, classify an outcome, or reconcile an
   indeterminate effect.

   One-time consumption is stateful and remains at the effect boundary.
   An offline SATISFIED result cannot prove that another executor has
   not already acted.  A consequential executor uses shared atomic state
   keyed by an executor-derived action instance and preserves an
   uncertain operation instead of blindly replaying it.

14.  Security Considerations

   *Presenter-selected sufficiency.* A presenter can construct a weak
   requirement that its own evidence satisfies.  The EP-AEC-
   REQUIREMENT-v1 object MUST come from relying-party configuration.
   C.requirement is descriptive only.

   *Presenter-selected action.* Agreement among components proves only
   internal agreement.  The expected action digest and CAID must be
   computed or selected by the protected boundary from the action it is
   actually preparing to perform.

Schrock                  Expires 4 February 2027               [Page 13]
Internet-Draft        Authorization Evidence Chains          August 2026

   *Cross-binding.* An attacker can splice individually valid artifacts
   for different actions.  Native verification before mapping and exact
   MATCH for each eligible component are required.  A label, shared
   principal, shared session, or similar-looking parameter is not a
   match.

   *Unbacked relations.* A presenter can claim that one artifact
   permits, delegates to, records, or supersedes another.  AEC credits a
   relation only when the trusted native verifier extracts the target
   evidence digest and relation from integrity-protected native bytes.
   An unbacked relation never satisfies a required binding.

   *Verifier and key-role confusion.* Native verifiers, revisions, trust
   anchors, mapping profiles, and human directories are relying-party
   pins.  They MUST NOT be accepted in the same transaction as
   presenter-controlled evidence.  A key trusted for one component role
   does not automatically satisfy another role.

   *Freshness and status.* Message freshness, artifact age, credential
   validity, credential revocation, authority revocation, and policy
   revision are separate checks.  A current credential does not make old
   per-action evidence fresh.  A replay record captures the checked
   instant and snapshots; it does not establish current status later.

   *Replay overclaiming.* Deterministic replay shows that the same
   normalized inputs produce the same evidence result.  It is not a
   refinement proof, a guarantee that a native verifier was correctly
   implemented, or proof that the recorded external status snapshot was
   honest.

   *Resource exhaustion.* Implementations MUST bound JSON depth, node
   count, component count, string bytes, expression tokens and depth,
   binding count, native verifier work, and diagnostic output.  Any
   bound exceeded is UNSATISFIED.

   *Host-language and transport boundaries.* Strict JSON parsing must
   reject duplicate member names before ordinary object construction can
   hide them.  AEC inherits the confidentiality and integrity properties
   of its transport.  The evidence and frozen action passed to later
   stages must not be mutable after evaluation.

   *Signature overclaiming.* A valid signature establishes only the
   signer and statement semantics of the selected native profile.  It
   does not inherently prove a natural person's identity, human
   operation, comprehension, legal authority, safety, execution, or
   outcome.

Schrock                  Expires 4 February 2027               [Page 14]
Internet-Draft        Authorization Evidence Chains          August 2026

15.  Privacy Considerations

   An AEC bundle can reveal identities, organizational roles,
   destinations, resources, policy choices, and timing.  Presenters and
   relying parties SHOULD disclose and retain only evidence needed by
   the selected requirement.  A plain digest of low-entropy personal
   data is not anonymization.

   The replay record SHOULD contain normalized facts and content
   digests, not unnecessary raw evidence.  Even those facts can reveal
   relationships and decision timing.  Access, retention, and
   correlation controls remain deployment responsibilities.

16.  Relationship to Other Work

   CAID [CAID] owns typed material-action identity and exact, relying-
   party-pinned cross-format mapping.  AEC uses CAID only after native
   verification and does not add trust semantics to a CAID.

   Authorization Receipts [EP-RECEIPTS] and Quorum [EP-QUORUM] define
   two native human-authorization components.  AEC composes them without
   generalizing all evidence into those formats.

   The earlier Action Evidence Graph draft (draft-schrock-ep-action-
   evidence-graph-00) described content-addressed graph references,
   relying-party evidence policy replay, a five-verdict classification,
   policy packs, and a signed reliance result.  This revision
   incorporates the useful composition substance into AEC: relying-
   party-owned evidence requirements, content-digested components, byte-
   backed relations, normalized facts, and a replay digest.  It
   intentionally does not adopt the EP-AEG-v1 graph envelope, five-
   verdict taxonomy, policy packs, or signed reliance-result format.

   Revision -04 superseded draft-schrock-ep-action-evidence-graph-00 for
   this evidence-composition and replay scope.  This revision preserves
   that consolidation.

   Agent Qualification Statements [EP-QUALIFICATION] can be verified as
   native components and can fill a relying-party-named qualification
   role.  Their observation and policy-satisfaction claims remain
   bounded by their native profile; qualification MUST NOT be converted
   into AUTHORIZED without the separate boundary decision and controls
   described by AEB.

Schrock                  Expires 4 February 2027               [Page 15]
Internet-Draft        Authorization Evidence Chains          August 2026

17.  IANA Considerations

   This document has no IANA actions.  It creates no universal
   component, relation, verifier, action-mapping, requirement, reason-
   code, or policy registry.

18.  Changes in -05

   *  Added a closed distinct-subject-quorum role constraint that counts
      only native-verifier-derived subject identities.

   *  Made the boundary between evidence sufficiency and AEB authority
      constraints explicit: initiator exclusion, executor exclusion,
      one-time consumption, and execution remain outside AEC.

   *  Clarified that qualification statements can fill a named evidence
      role but never authorize an action by themselves.

   *  Updated implementation status and successor references without
      changing the EP-AEC-v1 component envelope.

19.  Implementation Status

   The Apache-2.0 reference implementation includes native-verifier
   dispatch, exact action binding, bounded requirement evaluation,
   freshness and authenticated current-status checks, distinct-human
   quorum, deterministic evaluation records, and fail-closed
   configuration pins.  Same-team ports and shared vectors demonstrate
   implementation consistency; they are not independent implementations
   or proof that a deployment has complete mediation.

   The reference evaluator currently expresses its relying-party
   requirement as a bounded role expression and obtains distinct-human
   evidence through the native ep-quorum verifier.  The new
   role_constraints member and verifier-derived subject-counting
   algorithm specified in this revision are not yet implemented in that
   evaluator.  Implementations MUST NOT claim conformance to that part
   of this revision until they enforce the closed object and its refusal
   behavior.

20.  References

20.1.  Normative References

   [BCP14]    Internet Engineering Task Force, "Key Words for Use in
              RFCs to Indicate Requirement Levels", BCP 14, 2017,
              <https://www.rfc-editor.org/info/bcp14>.

Schrock                  Expires 4 February 2027               [Page 16]
Internet-Draft        Authorization Evidence Chains          August 2026

   [CAID]     Schrock, I., "The Canonical Action Identifier (CAID)",
              Work in Progress, Internet-Draft, draft-schrock-canonical-
              action-identifier-01, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-canonical-
              action-identifier/>.

   [EP-QUORUM]
              Schrock, I., "Multi-Party Quorum Authorization for High-
              Risk Agent Actions (EP-QUORUM)", Work in Progress,
              Internet-Draft, draft-schrock-ep-quorum-03, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-ep-
              quorum/>.

   [EP-RECEIPTS]
              Schrock, I., "Authorization Receipts for High-Risk Agent
              Actions", Work in Progress, Internet-Draft, draft-schrock-
              ep-authorization-receipts-08, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-ep-
              authorization-receipts/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

20.2.  Informative References

Schrock                  Expires 4 February 2027               [Page 17]
Internet-Draft        Authorization Evidence Chains          August 2026

   [EP-AEB]   Schrock, I., "The Action Evidence Boundary for
              Consequential Agent Effects", Work in Progress, Internet-
              Draft, draft-schrock-action-evidence-boundary-03, July
              2026, <https://datatracker.ietf.org/doc/draft-schrock-
              action-evidence-boundary/>.

   [EP-QUALIFICATION]
              Schrock, I., "Agent Qualification Statements", Work in
              Progress, Internet-Draft, draft-schrock-agent-
              qualification-statements-00, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-agent-
              qualification-statements/>.

Acknowledgments

   Review of adjacent work sharpened the separation among native
   validity, cross-format action mapping, evidence satisfaction, local
   authorization, credential status, human operation, and effect truth.
   Acknowledgment does not imply endorsement.

Author's Address

   Iman Schrock
   EMILIA Protocol, Inc.
   United States of America
   Email: team@emiliaprotocol.ai

Schrock                  Expires 4 February 2027               [Page 18]