| Internet-Draft | Authorization Evidence Chains | September 2026 |
| Schrock | Expires 1 April 2027 | [Page] |
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 keeps native cryptographic verification separate from relying-party acceptance, 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.¶
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 1 April 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.¶
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 verification is not sufficient for composition. A permit for action A and an approval for action B, each VERIFIED and ACCEPTED, do not jointly authorize either action. Likewise, two VERIFIED and ACCEPTED 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.¶
This document defines:¶
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.¶
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].¶
{
"@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.¶
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.¶
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.¶
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:¶
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.¶
The pinned trust inputs decide ACCEPTED. A verifier MUST NOT report an artifact as VERIFIED because its signer is pinned, or as ACCEPTED because its signatures verify.¶
Key-resolution material and the pinned trust inputs can live in one directory. Resolution uses only the mapping from a key reference to key bytes. Everything else a directory entry states about that key is a pinned trust input and decides ACCEPTED, not VERIFIED.¶
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:¶
A component reaches VERIFIED only when its native verifier's cryptographic and structural checks succeed, and reaches ACCEPTED only when it is VERIFIED and the pinned trust inputs for its component type accept it. The native verifier MUST report the two results separately. It MUST NOT report ACCEPTED for an artifact that is not VERIFIED, and MUST NOT report VERIFIED for an artifact whose integrity it did not check. When a native procedure checks trust inputs and cryptography together and cannot attribute a failure to one of them, the verifier reports the artifact as not VERIFIED. A component that is not both VERIFIED and ACCEPTED is ineligible.¶
When a format identifies its verification key only by reference, the
native verifier resolves the key from relying-party key material. If no
key can be resolved, VERIFIED cannot be evaluated: the artifact is not
VERIFIED, the normalized fact records its native verification as
NOT_EVALUATED with a reason such as key_unresolved, never as
FAILED, and the component is ineligible. Resolving a key does not make
the artifact ACCEPTED: whether that key is pinned for the component's
role, usable at the verification time, of an accepted class, and bound
to the principal the artifact names is decided by ACCEPTED. For such
formats VERIFIED depends on the resolved key as well as on the bytes, so
relying parties whose key-resolution material resolves the same
reference to different keys can reach different VERIFIED results for
the same bytes.¶
AEC MUST NOT accept a presenter's verified or
accepted Boolean, normalized fact, mapping result, key, trust
anchor, status assertion, or relation as a substitute for native
verification or relying-party acceptance.¶
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 carry the VERIFIED and ACCEPTED results separately and 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.¶
Native verification, relying-party acceptance, and material-action matching are distinct and ordered. Mapping MUST NOT inspect claims from an artifact that is not VERIFIED and ACCEPTED as authoritative input.¶
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.¶
A native verifier evaluates the pinned trust inputs against the action commitment the artifact itself carries and does not compare it with the expected action. An ACCEPTED artifact bound to a different action is ineligible because it is not MATCH, and its record says so; it is not reported as not ACCEPTED.¶
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 and acceptance, CAID mapping, or local authorization.¶
Given chain C and the acceptance inputs in Section 5, a verifier MUST proceed fail-closed:¶
For each component in array order:¶
role_constraints entry over eligible normalized facts only. A
failed or indeterminate role constraint yields UNSATISFIED.¶
The result MUST carry satisfied as a Boolean and SHOULD carry
bounded per-component reason codes. Each normalized fact MUST carry the
VERIFIED and ACCEPTED results as separate fields, and a consumer MUST
NOT derive one from the other. Reason codes SHOULD distinguish a
verification failure, a verification that could not be evaluated, an
acceptance refusal, and a failed material-action match from one
another. An implementation may
retain a legacy allow alias, but that alias MUST equal
satisfied and MUST NOT be interpreted as local AUTHORIZED.¶
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",
"algorithm_revision": "<evaluator algorithm revision>",
"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": [
{
"component_index": 0,
"type": "ep-quorum",
"evidence_digest": "sha256:<hex>",
"native_verification": "VERIFIED",
"acceptance": "ACCEPTED",
"mapping_verdict": "MATCH",
"...": "further normalized fact members"
}
],
"satisfied": true,
"reasons": []
}
¶
The algorithm_revision identifies the evaluation algorithm
and fact members the evaluator implements. An evaluator implementing
the algorithm and fact members of this revision of this document sets
it to the string EP-AEC-EVALUATOR-07-v1; a later revision that
changes either assigns a new value. Records with different
algorithm revisions are not compared digest for digest; a record from an
evaluator implementing -06 of this document carries one combined
validity member per fact instead of native_verification and
acceptance. 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.¶
In each fact, native_verification is VERIFIED,
FAILED, or NOT_EVALUATED, and acceptance is
ACCEPTED, REJECTED, or NOT_EVALUATED.
acceptance is NOT_EVALUATED whenever
native_verification is not VERIFIED.
native_verification is NOT_EVALUATED when the native
verifier was not invoked, returned no usable result, or could not
evaluate VERIFIED because no verification key could be resolved; it is
FAILED only when the checks ran and did not pass.¶
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. ACCEPTED depends on trust snapshots, and status checks depend on status services; therefore the replay record MUST bind the selected verifier-profile, trust-snapshot, and status-snapshot digests needed to identify those inputs. A party that re-runs the evaluation with the same verification keys under different trust inputs can reproduce the VERIFIED results but not necessarily the ACCEPTED results; the trust-snapshot digests identify whose acceptance the record reports. 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.¶
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-authorization-bundle, ep-receipt, or
ep-quorum explicitly, according to the native artifact's role.¶
The ep-authorization-bundle component carries the
pre-execution Authorization Bundle of [EP-RECEIPTS],
Section 6. Its native verifier MUST report VERIFIED only when the
bundle's closed structure, action and context commitments, and
completed signoff signatures under the keys its signoffs reference
verify, and MUST report ACCEPTED only when the relying-party-selected
policy, approver selection, approver keys, their directory status and
key classes, and required status and presentation evidence are accepted
under that profile. Whether the bundle's action is the exact expected action is
established by MATCH under Section 7. Distinct subjects
MUST come only from verified completed signoffs, not from an unsigned
label or the wider selected approver roster. A SATISFIED bundle is
approval evidence, not proof of consumption or execution.¶
The ep-receipt built-in MUST report VERIFIED only when the
Trust Receipt's signoff signatures verify under the keys their approver
key identifiers resolve to and its log checkpoint signature verifies
under the relying party's pinned log key, which the offline
verification algorithm of [EP-RECEIPTS], Section 7.3,
takes as an input. The checkpoint check therefore combines a trust
input with cryptography: a checkpoint that does not verify under the
pinned log key is not VERIFIED (Section 6),
whether it was forged or signed by another log, and without a pinned
log key VERIFIED cannot be evaluated. The built-in MUST report ACCEPTED
only for a VERIFIED Trust Receipt that meets a relying-party profile
pinning the approver directory, accepted key class, WebAuthn RP ID and
signed-origin allowlist where required, policy hash, 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. A terminal
Trust Receipt and a pre-execution Authorization Bundle MUST NOT be
substituted for one another. Verifying a consumed receipt does not
restore authority or permit another execution.¶
The ep-quorum built-in MUST report VERIFIED only when the
quorum structure is intact, every member context commits to the quorum
action_hash, and every member signoff verifies under the public
key that member carries. The built-in MUST report ACCEPTED only when the
presented quorum policy equals the relying-party-pinned policy and the
selected approver, role, distinctness, origin, ordering, and freshness
rules of [EP-QUORUM] hold. A safety-critical profile
requiring human separation MUST require at least two distinct humans. A
quorum that is VERIFIED under presenter-selected keys or a weaker
presenter-selected policy is not ACCEPTED and 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.¶
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 operation record is VERIFIED and ACCEPTED and binds the exact
action, the capability that record references and that capability's
issuance authorization are each VERIFIED, and ACCEPTED under the
relying party's pins for its own role, and the native verifier's scope
result places the operation within that capability. The component is
not VERIFIED unless the operation record and both referenced artifacts
are VERIFIED, and not ACCEPTED unless all three are ACCEPTED and the
native verifier's scope result places the operation within that
capability. An operation outside the capability's scope is therefore
not ACCEPTED even when all three artifacts are ACCEPTED. A native
procedure that checks a referenced artifact's trust inputs and
cryptography together and cannot attribute a failure falls under the
rule of Section 6. AEC does not query or
reserve current budget. A capability component MUST NOT satisfy
ep-receipt, ep-quorum, or another human role.¶
AEC occupies one deliberately narrow transition in the effect-boundary lifecycle described by [EP-AEB]:¶
native VERIFIED -> relying-party ACCEPTED -> material-action MATCH -> AEC SATISFIED -> local AUTHORIZED -> atomic CONSUMED or RESERVED -> INVOKED -> EXECUTED, FAILED, or INDETERMINATE¶
This document splits the VERIFIED step of that lifecycle into two
results. An artifact that [EP-AEB] calls VERIFIED, one
that passed its native verifier under relying-party-selected trust
inputs, is VERIFIED and ACCEPTED here. FAILED and INDETERMINATE in the
last line are execution outcomes of [EP-AEB]; they are
distinct from the native_verification value FAILED
(Section 10) and the CAID verdict INDETERMINATE
(Section 7).¶
AEC can orchestrate native verification, acceptance, and mapping itself or consume trusted internal results from the same protected boundary. In both arrangements, VERIFIED precedes ACCEPTED, ACCEPTED precedes MATCH, and all three precede SATISFIED. AEC MUST NOT collapse ACCEPTED into VERIFIED or 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.¶
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 VERIFIED and ACCEPTED artifacts for different actions. Native verification and acceptance 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. An artifact signed by a key that is not pinned for its role can be VERIFIED; it is never ACCEPTED for that role.¶
Verification and acceptance. If trust decisions are folded into VERIFIED, a forged or malformed artifact and an intact artifact from a signer the relying party does not trust produce the same result, and a replay record states more than the relying party's pins support. Keeping the results separate lets a later reader who holds the evidence and the same verification keys re-derive VERIFIED without adopting the original relying party's trust decisions, and keeps ACCEPTED attributable to identified trust snapshots. Neither result alone makes a component eligible. The separation has limits. An unresolvable key reference is recorded as NOT_EVALUATED, not FAILED. Where a format does not identify its verification key at all, or a native procedure cannot attribute a failure, FAILED does not distinguish a forgery from an intact artifact signed under a key the relying party does not hold. An artifact bound to a different action is a failed MATCH, not a refused acceptance.¶
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.¶
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.¶
CAID [CAID] owns typed material-action identity and exact, relying-party-pinned cross-format mapping. AEC uses CAID only after native verification and acceptance and does not add trust semantics to a CAID.¶
Authorization Receipts [EP-RECEIPTS] and Quorum [EP-QUORUM] define native human-authorization profiles. 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.¶
This document has no IANA actions. It creates no universal component, relation, verifier, action-mapping, requirement, reason-code, or policy registry.¶
native_verification and acceptance members,
the replay record gains algorithm_revision (value
EP-AEC-EVALUATOR-07-v1 for this revision) and binds
trust-snapshot digests, and reason codes SHOULD distinguish a
verification failure, a verification not evaluated, an acceptance
refusal, and a failed match (Sections 9 and 10).¶
distinct-subject-quorum role constraint that
counts only native-verifier-derived subject identities.¶
The Apache-2.0 JavaScript reference implementation provides
createAuthorizationChainEvaluator for the structured
EP-AEC-REQUIREMENT-v1 contract. Configuration captures the relying
party's requirement, native-verifier profiles, trust snapshots, and
optional action mappings before evaluation. The evaluator implements
exact expected-action matching, native-derived subject constraints,
required byte-backed bindings, required freshness and authenticated
status checks, and EP-AEC-REPLAY-v1 records. Replay re-verifies the
original evidence under those configuration pins; serialized facts
are not trusted merely because their digest matches.¶
The evaluator revision that accompanies this document separates the two results. Native verifier callbacks return separate verified and accepted results; every replay fact records native_verification and acceptance; a callback result that reports ACCEPTED without VERIFIED, or that carries only the earlier combined validity flag, is refused. The built-in ep-quorum verifier checks integrity under the public keys a quorum carries. The built-in ep-receipt, ep-authorization-bundle, and platform-attestation verifiers resolve each key reference from pinned key material and check signatures under the resolved key only; a reference that cannot be resolved is recorded as NOT_EVALUATED, and the directory entry's approver binding, key class, validity period, and compromise marker are acceptance inputs. The Trust Receipt checkpoint signature is checked under the relying party's log key, so a checkpoint that does not verify under that key is FAILED whether it was forged or signed by another log. The built-ins evaluate pins against the action the artifact carries and leave the expected action to MATCH.¶
The older string-requirement API remains a separate legacy interface.
It does not implement the complete structured contract and keeps one
combined validity flag per component. The new
evaluator also dispatches the explicit pre-execution
ep-authorization-bundle component. Evidence satisfaction neither
authorizes execution nor reserves, consumes, or reconciles authority.¶
The associated tests are same-team reference evidence, not an independent implementation, a proof of all native verifier profiles, or complete deployment mediation. Custom native verifiers and mapping callbacks remain trusted configuration. Input sizes and asynchronous verifier work are bounded; untrusted synchronous callback code requires separate process or worker isolation.¶
Review of adjacent work sharpened the separation among native verification, relying-party acceptance, cross-format action mapping, evidence satisfaction, local authorization, credential status, human operation, and effect truth. Acknowledgment does not imply endorsement.¶