Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)

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

This Internet-Draft will expire on 22 January 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

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

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" 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.¶

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

{
  "@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.¶

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"],
  "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.¶
• 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.¶

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¶
• 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.¶

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

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:¶

   1. Compute its evidence digest. If a presented evidence digest exists and differs, mark the component ineligible.¶
   2. 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.¶
   3. Only after native VERIFIED, establish material-action MATCH under Section 7. A different or indeterminate action makes the component ineligible.¶
   4. 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.¶
   5. 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.¶
   6. 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.¶
5. Construct the satisfied type set from eligible components only and evaluate the relying-party expression.¶
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.¶

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

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

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

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 [EP-AEG] 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.¶

If draft-schrock-ep-authorization-evidence-chain-04 is published, it is intended to supersede draft-schrock-ep-action-evidence-graph-00 for this evidence-composition and replay scope. Until publication, the posted AEC-03 and AEG-00 remain their respective public snapshots; a local staged source does not replace an Internet-Draft.¶

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 -04

• Defined EP-AEC-REQUIREMENT-v1 so expression, freshness, status, and required inter-artifact bindings are pinned by the relying party.¶
• Defined normalized native facts and EP-AEC-REPLAY-v1 without changing the EP-AEC-v1 component envelope or creating a signed reliance-result format.¶
• Made native VERIFIED, CAID material-action MATCH, AEC SATISFIED, local AUTHORIZED, and effect outcomes distinct ordered states.¶
• Required inter-artifact bindings to come from integrity-protected native bytes rather than presenter-asserted graph edges.¶
• Integrated the useful evidence-policy replay substance of AEG-00 while declining its separate graph envelope, policy packs, and five-verdict taxonomy.¶
• Clarified that AEG-00 is superseded for this scope only if -04 is published.¶

19. Implementation Status

The existing reference verifier implements the EP-AEC-v1 envelope, native-verifier dispatch, exact action-digest binding, bounded Boolean requirement evaluation, relying-party requirement precedence, built-in human legs, and SATISFIED or UNSATISFIED. Same-team TypeScript, Python, and Go implementations consume shared vectors; this is cross-language consistency testing, not independent implementation.¶

The repository also contains an experimental implementation and tests for content-digested evidence nodes, required byte-backed relations, freshness evaluation, deterministic replay digests, and signed reliance results from the earlier AEG design. As of this revision date, the combined EP-AEC-REQUIREMENT-v1 and EP-AEC-REPLAY-v1 contract in this document is not yet covered by the three-language AEC vector suite. Therefore the repository MUST NOT be described as a complete conforming implementation of -04 until those combined vectors and implementations exist.¶

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