Trust Me, I Checked: Verifiable Third-Party Decision Binding at the Execution-Finality Boundary

Introduction

Vulnerability: "Trust Me, I Checked" Distributed systems frequently separate the component that makes a security decision from the component that produces the protected effect. An API server can rely on an authorization service; an AI-agent runtime can rely on an independent policy engine; a payment service can rely on fraud, sanctions, or risk services; a cloud controller can rely on external authorization; and an operation can rely on a remote-attestation Verifier. This separation is useful, but it creates a security question when the effectuation component cannot independently distinguish a real external decision from an intermediary's assertion that the decision occurred.

The unprovable third-party check Candidate Act C | v +-----------------------+ | Intermediary / RS | | | | "Authority Y checked | | this and said ALLOW" | +-----------+-----------+ | | no independently verifiable, | act-bound decision required here v +-----------------------+ | Protected Effect K | +-----------------------+ The intermediary can be honest and the architecture can still be underspecified. The prevention property depends on what the final effectuation boundary can verify and what that boundary is technically required to verify, not merely on whether an upstream log says that a call was made.

Existing Solutions Already Address Important Parts OAuth Token Introspection allows a protected resource to query an authorization server for the current active state and metadata of an access token . Where the protected resource itself controls the non-bypassable consequence and obtains all required current authorization semantics directly, a separate portable evidence artifact can be unnecessary. Signed authorization-evidence work is even closer to this problem. The current draft defines signed pre-execution authorization records for WIMSE-authorized AI-agent actions and binds a Permit to canonical request material. Its companion SCITT profile defines a profile for pre-execution authorization records. This document does not claim that signed authorization evidence, exact-request binding, or Permit records are new. SCITT provides an architecture for signed statements, transparency, registration, and receipts. RATS provides a mature architecture for Evidence, Verifiers, Attestation Results, Reference Values, and appraisal. HTTP Message Signatures provide integrity and authenticity over selected HTTP message components. Transaction Tokens maintain and propagate identity and authorization context through trusted-domain call chains. WIMSE addresses workload identity and security context across multi-system environments. These mechanisms are treated as complementary. Any one of them, or a combination, can already satisfy some or all of the invariant in a concrete deployment when the actual effectuation boundary verifies the exact required decision and the protected consequence cannot bypass that verification.

Why the Residual Gap Can Remain The residual gap is not "existing standards cannot carry evidence." They can. The gap exists only where the system has not established the complete semantic chain from the required external decision to the protected effect. With Token Introspection, the residual question appears when the introspecting Resource Server is not itself the final consequence boundary, or when a downstream worker, queue, database, device, or other component can effect the operation without preserving the decision dependency. With HTTP Message Signatures, authentic request components do not by themselves prove that a separate authority evaluated and approved the semantic act. With RATS, a valid Attestation Result can establish a trust decision about an Attester; the residual question is whether that result is applicable to and required for the concrete consequential act. With SCITT, a signed or registered statement can provide strong provenance, transparency, and accountability; the residual question is whether the statement semantically authorizes the pending act and is made a mandatory input before effectuation rather than merely an audit artifact. The Munoz Permit work is the closest overlap. A deployment in which the actual non-bypassable effectuation boundary verifies a current applicable Permit for the exact request may already provide the property sought here. This draft therefore asks reviewers to identify whether any residual architectural requirement remains. If the Permit/Closure/SCITT model already guarantees the full invariant for the intended deployment class, this document should be narrowed, merged, or withdrawn rather than claim a false gap.

What This Architecture Introduces The proposed contribution is an effectuation-time composition invariant. A deployment defines which external decision authorities are required for a Candidate Act. Each required decision must be represented by independently verifiable External Decision Evidence, or must be re-established through an authenticated live query with equivalent semantics, and the Finality Sink must make those decisions load-bearing before protected commit.

Bind the required external decision to the exact Candidate Act.
Identify the authority that actually made the decision.
Bind or re-establish the relevant decision basis, generation, or current state.
Apply freshness, replay, audience/sink, and authorized-use constraints where required.
Support multiple required authorities without treating one successful decision as universal approval.
Keep the Candidate Act non-effective until the Finality Sink verifies the complete required decision set.
Require the decision dependency to survive to the actual effectuation boundary and across any alternate path.
Distinguish prevention from auditability, provenance, accountability, or detection.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Direct Question: What Threat Does This Architecture Solve? If system X is required to obtain a decision from independent authority Y before producing consequence K, can X, an intermediary, or a downstream component cause K while falsely claiming that Y approved the exact act? Required(Y, C, K) AND No valid applicable decision from Y ==> K MUST remain non-effective The architecture targets the difference between a statement about a check and a load-bearing, independently verifiable decision dependency.

Motivating Scenario: Fabricated or Misbound External Approval Consider a high-consequence transfer that requires authorization-service approval and a separate risk-service decision. The application obtains both at t0. Before final commit, the application changes the destination, or it reuses a previous risk ALLOW for another amount. Alternatively, a compromised application simply asserts that the risk service returned ALLOW without contacting it.

Verifiable external-decision binding +-------------------------+ Candidate C ---->| Decision Authority A | | evaluate exact act | +------------+------------+ | | E_A = | protected decision evidence v Candidate C -------------> +-----------------------+ | FINALITY SINK | | verify issuer | | verify H(C) | | verify basis/current | | verify freshness | | verify sink/use | +-----------+-----------+ | v PROTECTED EFFECT K The Finality Sink does not need to know how A internally reached its decision. It needs to establish that the recognized authority made the required decision, that the evidence applies to the exact pending act and current conditions required by the deployment, and that effectuation cannot proceed without that result.

Problem Space

Decision Provenance Is Not Decision Applicability Cryptographic proof that authority A issued evidence E does not prove that E applies to Candidate Act C now. Applicability can depend on act identity, principal, resource, purpose, policy generation, revocation state, risk state, audience, sink, freshness, or authorized-use constraints.

Evidence Is Not Execution Authority Possession of a valid evidence object SHOULD NOT automatically confer unrestricted execution authority. A decision artifact can be evidence that a predicate was satisfied without becoming a reusable bearer credential for other acts or sinks.

Audit Is Not Prevention A signed decision record, SCITT Receipt, log entry, or closure record can provide strong audit and accountability. If it is created or checked only after the protected effect, it does not establish the prevention property defined here.

Threat Model and Assurance Scope

Adversary Capabilities The adversary MAY control or compromise the requester, AI agent, application process, intermediary Resource Server, orchestration layer, ordinary host software, evidence cache, local audit/logging layer, queue producer, downstream worker, or network path outside cryptographically protected channels. The adversary MAY omit a required external query, fabricate a local ALLOW, suppress a DENY or challenge, replay authentic evidence, substitute evidence between acts, alter an act after evidence issuance, present evidence to a different sink or tenant, use stale evidence after a policy/revocation change, reorder authority results, or present only a subset of the required authority set.

Threat Severity and Applicability Severity is consequence-dependent rather than universally critical. The issue deserves high attention where an external decision is a mandatory condition for financial settlement, fraud/AML/sanctions processing, sensitive-data release, model-weight or confidential-compute egress, cloud administrative changes, AI-agent actions, device or operating-system actions, industrial actuation, cross-jurisdiction data movement, critical network operations, or remote-attestation-dependent protected actions. In those systems, a false or misbound claim that "the independent check passed" can be equivalent to bypassing the control entirely.

Baseline Third-Party-Decision Profile The requester, intermediary, network, and ordinary application software are untrusted. Required external decision authorities, configured verification roots, authoritative current-state sources where required, and the Finality Sink are trusted to follow the protocol.

High-Assurance Third-Party-Decision Profile A higher-assurance deployment MAY additionally assume compromise of the general-purpose operating system, agent runtime, orchestration plane, local policy service, ordinary evidence cache, and audit storage. In that profile, evidence verification, relevant current-state anchoring, and protected commit MUST occur in a protection domain that the compromised components cannot rewrite or bypass. Possible substrates include a protected transaction service, HSM or security processor, TEE or secure monitor, DPU or SmartNIC, protected storage/controller, or another independently enforceable boundary appropriate to the system.

Trusted Roots and Limits The base model assumes the cryptographic primitives remain secure and at least one configured trust root for each required authority remains trustworthy. Compromise of every required decision authority, compromise of the Finality Sink itself, or a consequence reachable outside the declared effectuation domain is outside the base prevention claim.

Design Goals and Non-Goals The goal is to make externally produced decisions independently verifiable and load-bearing at the effectuation boundary without defining a universal policy language or universal evidence token. This document does not define a new OAuth grant type, a new SCITT statement format, a new RATS evidence format, a new signature algorithm, a new transaction token, or a universal decision protocol. Existing formats and live authenticated queries can satisfy the model. The document also does not claim that every high-consequence act requires a third-party authority. The required authority set is deployment policy.

Existing Mechanisms and the Proposed Delta

OAuth Token Introspection RFC 7662 defines a method for a protected resource to query an OAuth authorization server about token active state and metadata . A live authenticated query immediately before a non-bypassable protected effect can be a strong way to satisfy current-decision requirements. The residual question exists only when the token state does not represent all required external decisions, the introspecting Resource Server is not the final consequence boundary, or downstream effectuation can proceed without preserving the decision.

Signed Authorization Evidence and the Munoz Permit defines signed authorization-evidence records for WIMSE-authorized AI-agent actions. The Permit commits to canonical request material, and the draft discusses independently verifiable pre-execution authorization evidence. defines a SCITT profile for such records. This is direct and important overlap. This document does not propose a competing Permit format. A valid current Permit verified by the actual non-bypassable Finality Sink can instantiate External Decision Evidence. Reviewers are specifically asked whether that architecture already supplies the full invariant, in which case this document should be narrowed or merged.

SCITT RFC 9943 defines an architecture for signed statements, transparency, registration, and verifiable receipts . These properties can strengthen issuer attribution, provenance, auditability, and accountability. The execution-finality question is semantic and temporal: does the protected effect require an applicable decision by the required authority for this exact pending act? Registration or receipt verification is not automatically equivalent to that condition, although a SCITT profile can carry or strengthen the required evidence.

RATS and Attestation Results RATS defines Evidence, Verifiers, Attestation Results, Endorsements, Reference Values, and Relying Party appraisal . An Attestation Result can be an external decision input to a consequential action. This document does not redefine attestation. It asks whether a required Attestation Result remains applicable to the concrete act and is technically required at the later consequence boundary. If the Relying Party already controls that effect and enforces those semantics, no additional finality layer is required merely for duplication.

HTTP Message Signatures RFC 9421 provides integrity and authenticity over selected HTTP message components . It can protect an external-decision request, response, or covered act parameters. Message authenticity alone does not define the application proposition "recognized authority A evaluated this exact Candidate Act under basis B and approved it for sink S". A profile can use HTTP Message Signatures to protect that proposition.

OAuth Transaction Tokens maintains and propagates identity, workload identity, and authorization context through call chains within a trusted domain. Such context can help preserve decision lineage across multi-service processing. This document does not duplicate Transaction Tokens. Its separate question is whether a particular external decision that is mandatory for the final effect is independently established and load-bearing at effectuation.

WIMSE WIMSE addresses workload identity and security context across multi-system and multi-hop environments . Its ecosystem is directly relevant to carrying the identities of decision authorities and executing workloads. External Decision Evidence can compose with WIMSE context without redefining WIMSE identifiers or workload credentials.

What Is New in This Document The proposed contribution is not signatures, authorization evidence, receipts, introspection, attestation, or decision provenance by themselves. It is a vendor-neutral effectuation-time invariant: If authority A_i is REQUIRED for Candidate Act C and consequence K, then K cannot become effective unless the Finality Sink independently establishes an applicable decision from A_i for that exact act under the required current-state and authorized-use semantics. Existing mechanisms that already provide that property for a deployment already satisfy the architecture. The document is useful only to the extent that stating the invariant and its composition requirements exposes gaps between evidence generation and effectuation.

Prevention, Mitigation, and Auditability

Prevention Profile Prevention of the governed fabricated/omitted/misbound-decision class can be claimed only when the required authority set is defined, the Finality Sink independently verifies the required decision set, each decision applies to the exact act and required current state, evidence cannot be substituted outside permitted context, and no alternate path can create the protected consequence without equivalent verification. Defined required authorities + exact-act decision binding + trusted issuer verification + currentness / freshness / revocation semantics + sink or authorized-use binding where required + non-bypassable effectuation + atomic or equivalent verification-to-commit coupling = PREVENTION of the governed missing/misbound-decision class

Mitigation or Accountability Profile If the intermediary merely claims that it checked, evidence is checked after effect, evidence is not exact-act bound, stale evidence is accepted, only some required authorities are represented, or the protected effect has a bypass path, the system provides mitigation, accountability, detection, or auditability rather than the same prevention guarantee.

Terminology Candidate Act: A proposed consequence-bearing operation that can be computed, queued, or authorized but has not yet been permitted to create the protected consequence. Protected Consequence: The external, persistent, financial, physical, disclosure, administrative, or other effect governed by the deployment. External Decision Authority (EDA): An independently recognized authority whose decision is required for a particular Candidate Act or class of acts. External Decision Evidence (EDE): Protected evidence, or an authenticated live decision result with equivalent semantics, establishing that an EDA issued a decision relevant to a Candidate Act. EDE is an architectural role, not a required wire format. Required Decision Authority Set: The set or rule defining which EDAs must provide acceptable decisions for the Candidate Act. Decision Basis: Security-relevant policy, reference, risk, revocation, trust, account, purpose, jurisdiction, or other state used by an EDA to make its decision. Decision-Basis Generation: A version, epoch, digest, status root, or equivalent identity for load-bearing decision state. Evidence Applicability: The property that EDE applies to the exact Candidate Act, recognized authority, current required state, audience/sink and authorized-use context. Non-Effective State: A condition in which a Candidate Act can be prepared and validated while the requester still lacks the means to produce the protected consequence without final enforcement. Finality Sink: The protected functional boundary controlling the first transition that makes the Candidate Act externally effective. Protected Commit: The transition or serialization point after which the protected consequence becomes effective under the deployment model.

External Decision Evidence Model Let C be the concrete Candidate Act, K the protected consequence, S the Finality Sink, A_i a required external decision authority, B_i its decision basis, G_i a generation or equivalent current-state identifier, N a freshness value, and U the authorized-use constraints. Conceptual evidence role: E_i = Protect_Ai( H(C), Decision_i, H(B_i) or BasisReference_i, G_i, N, AudienceOrSink_i, U_i, EvidenceIdentifier_i) This is a semantic model, not a mandated token encoding. The deployment need not carry every field explicitly. A field can be re-established through an authenticated current-state query or protected local state if the resulting invariant is equivalent.

Formal Mathematical Model Let R(C) be the Required Decision Authority Set for Candidate Act C. Define EvidenceValid for evidence E_i from authority A_i as follows: EvidenceValid(E_i, A_i, C, S, State_now) := IssuerTrusted(E_i, A_i) AND IntegrityValid(E_i) AND ExactActBinding(E_i, C) AND DecisionAllows(E_i, C) AND DecisionBasisApplicable(E_i, State_now) AND FreshnessValid(E_i, State_now) AND AudienceOrSinkValid(E_i, S) AND AuthorizedUseValid(E_i, C, S) AND ReplayRuleSatisfied(E_i) A profile MAY define some predicates as TRUE by construction. For example, a live mutually authenticated query whose response cannot be replayed outside the channel can satisfy freshness or audience properties differently from a portable signed object. RequiredEvidenceSatisfied(C, S, State_now) := FOR ALL A_i in R(C): EXISTS E_i such that IssuedBy(E_i, A_i) AND EvidenceValid(E_i, A_i, C, S, State_now) The base safety invariant is: Effective(K, C) ==> RequiredEvidenceSatisfied(C, S, State_now) AND FinalityPredicate(C, S, State_now) = TRUE AND EffectuationPathAuthorized(C, S) For a strict prevention profile inside the declared threat and effectuation domain: NOT RequiredEvidenceSatisfied(C, S, State_now) ==> NOT Effective(K, C)

Bounded Prevention Argument Assume that (1) every required authority in R(C) is correctly identified; (2) an attacker cannot forge acceptable evidence for an uncompromised required authority; (3) the Finality Sink independently verifies RequiredEvidenceSatisfied before commit; (4) the verification-to-commit relation is atomic or protected by an equivalent ordering rule; and (5) every path capable of producing K under the declared threat model crosses an equivalent Finality Sink. Under those assumptions, an attacker cannot cause K while omitting, fabricating, or substituting a required external decision without violating at least one explicit assumption. This argument is intentionally bounded. It is not proof that an EDA's policy is correct, that its internal reasoning is trustworthy, or that consequences outside the declared effectuation domain are controlled.

Candidate and Authority ModelLet C be the canonical Candidate Act, K the protected consequence, S the Finality Sink, A_i an external decision authority, E_i evidence associated with A_i, B_i the decision basis used by A_i, G_i a currentness or policy generation, N a freshness/challenge value, and U_i authorized-use constraints. Let R(C) be the protected rule describing which authority decisions are required for C. C = canonical security-relevant Candidate Act K = protected consequence S = Finality Sink A_i = external decision authority i E_i = evidence / live response associated with A_i B_i = decision basis used by A_i G_i = basis/policy/currentness generation N_i = freshness challenge / nonce if required U_i = authorized-use constraints R(C) = protected authority-composition rule for C

Abstract Evidence SemanticsExternal Decision Evidence is an architectural role, not a mandatory wire format. A portable object can conceptually bind the following semantics even when the actual protocol uses different fields or a live authenticated exchange. E_i := Protect_Ai( issuer = A_i, act_digest = H(C), decision = d_i, basis_digest = H(B_i), generation = G_i, freshness = N_i, audience_or_sink = S_if_required, use_constraints = U_i, evidence_id = id_i) A live query MAY satisfy equivalent semantics without constructing this literal object. What matters is that the sink can independently establish the issuer, exact act, decision, currentness, freshness, and applicable-use semantics before effectuation.

Evidence Validity Predicate EvidenceValid(E_i, A_i, C, S, State_now) := IssuedBy(E_i, A_i) AND IssuerTrustedForDecisionClass(A_i, C) AND IntegrityOrChannelAuthenticityValid(E_i) AND ExactActBinding(E_i, C) AND DecisionSemanticsValid(E_i) AND DecisionAllows(E_i, C) AND DecisionBasisApplicable(E_i, State_now) AND GenerationApplicable(E_i, State_now) AND FreshnessValid(E_i, State_now) AND AudienceOrSinkValidIfRequired(E_i, S) AND AuthorizedUseValid(E_i, C, S) AND ReplayRuleSatisfied(E_i, C, S) AND EvidenceNotSuperseded(E_i, State_now) A profile can make some predicates true by construction. For example, a mutually authenticated live query with a sink-generated nonce can satisfy issuer, audience, and freshness differently from a portable signed object.

General Authority-Composition RuleThe required-authority policy need not be a simple conjunction. A protected rule can contain mandatory authorities, alternative authorities, thresholds, role classes, negative-decision precedence, or conditional dependencies. Rule R(C) may contain: MANDATORY(A_authz) ANY_OF({ A_fraud_primary, A_fraud_backup }) THRESHOLD( k = 2, authorities = { A_risk_1, A_risk_2, A_risk_3 }) REQUIRE_IF( predicate = HighValue(C), authority = A_human_approval) DENY_OVERRIDES({ A_safety, A_compliance }) The rule itself is load-bearing security state. An attacker must not be able to weaken R(C), silently remove a required authority, or reinterpret UNKNOWN/TIMEOUT as ALLOW.

Authority-Rule Evaluation DecisionState(A_i,C) ∈ { ALLOW, DENY, CHALLENGE, UNKNOWN, UNAVAILABLE } RuleSatisfied(R(C), E, State_now) := EvaluateProtectedRule( R(C), per_authority = { A_i -> EvidenceValid(E_i,A_i,C,S,State_now) ? DecisionState(A_i,C) : UNKNOWN }) For a strict prevention profile, every rule construct must define DENY, CHALLENGE, UNKNOWN, UNAVAILABLE, and conflicting-decision behavior. Undefined composition semantics are not a valid prevention rule.

Authority Dependency GraphSome external decisions depend on earlier decisions or shared context. Let D_A(C) be a directed acyclic authority-dependency graph when ordering is required. D_A(C) = (Authorities, DependsOn) Example: A_identity ----> A_authz ----> A_fraud \ +-------> A_compliance Validity condition: If A_j depends on A_i, then evidence for A_j MUST identify, directly or by protected context reference, the decision basis or transaction state in which A_i's result was incorporated. A cycle in the dependency graph is either invalid or requires an explicitly defined fixed-point/transaction protocol; this document does not silently assume cyclic dependencies are safe.

Exact-Act Binding ExactActBinding(E_i,C) := H(CanonicalSecurityAct(C)) = E_i.act_digest CanonicalSecurityAct(C) MUST cover every field whose change can: alter the protected consequence, alter the authority decision, alter destination/audience, alter purpose/use, alter target resource, alter amount/parameter/state transition. If an authority intentionally approves a class of acts rather than one exact act, the evidence must explicitly encode the allowed class and the sink must verify that C is inside that class. Class authorization is not treated as exact-act binding by accident.

Decision-Basis Currentness BasisApplicable(E_i, State_now) := BasisIdentityKnown(E_i) AND ( E_i.generation == CurrentGeneration(A_i,C) OR AuthoritativeCompatibilityProof( E_i.generation, CurrentGeneration(A_i,C), C) ) AND NoApplicableRevocationAfterDecision(E_i,C) An authentic decision can become stale after policy, risk, trust, resource, account, or revocation state changes. Signature validity is therefore not equivalent to decision currentness.

Replay and Non-Bearer Semantics NonBearerUseValid(E_i,C,S,Txn) := ExactActBinding(E_i,C) AND SinkBindingValidIfRequired(E_i,S) AND TransactionBindingValidIfRequired(E_i,Txn) AND FreshnessValid(E_i) AND ( ReusableByPolicy(E_i,C,S) OR ConsumeOnce(E_i.id, Txn) ) Evidence can be independently verifiable without being bearer authority. Possession alone need not be sufficient to exercise the protected effect.

Live-Query Equivalence LiveDecisionValid(Q_i, A_i, C, S, N, State_now) := MutuallyAuthenticatedPeer(Q_i) = A_i AND Q_i.challenge = N AND Q_i.act_digest = H(C) AND Q_i.decision = ALLOW AND Q_i.basis_current(State_now) AND Q_i.sink_valid_if_required(S) Portable evidence is NOT required if: LiveDecisionValid(...) supplies equivalent semantics.

Required Decision Satisfaction RequiredDecisionSatisfied(C,S,E,State_now) := RuleIntegrityValid(R(C)) AND RuleSatisfied(R(C), E, State_now) AND AllMandatoryNegativeDecisionsAbsent(R(C),E) AND AllDependencyConstraintsSatisfied(D_A(C),E) AND CurrentnessConstraintsSatisfied(E,State_now)

Verification-to-Commit SerializationThe decision set can become stale after verification but before effect. Let ≺_S be the authoritative serialization order protecting load-bearing state and protected effect commit. Let: VerifySet(C,E,g) = successful decision-set verification Change(g -> g+1) = load-bearing policy/revocation/trust change CommitEff(C) = protected effect commit If: VerifySet(C,E,g) ≺_S Change(g -> g+1) ≺_S CommitEff(C) then: verification under g MUST NOT authorize CommitEff(C) unless an authoritative compatibility/survival rule says the change is irrelevant to C.

Strict Effectuation Invariant Effective(K,C) => RequiredDecisionSatisfied(C,S,E,State_now) AND FinalityPredicate(C,S,State_now) = TRUE AND EffectuationPathAuthorized(C,S) AND VerificationGenerationCurrent(C,E,State_now) Strict prevention: NOT RequiredDecisionSatisfied(C,S,E,State_now) => NOT Effective(K,C)

Expanded Bounded Prevention ProofAssume: (1) R(C) is integrity-protected and complete for the deployment; (2) uncompromised required authorities cannot be impersonated; (3) exact-act or explicit class binding is verified; (4) currentness/revocation/freshness rules are enforced; (5) the Finality Sink independently verifies the authority rule; (6) verification and commit are serialized against load-bearing state changes; and (7) every path capable of producing K crosses equivalent enforcement.Suppose K becomes effective even though a required authority decision is missing, stale, inapplicable, substituted, or negative. Then RequiredDecisionSatisfied is false. The strict prevention invariant prohibits effectuation, contradicting the assumed effect unless at least one premise — rule completeness, authority authenticity, exact-act binding, currentness, sink integrity, serialization, or path completeness — failed. This proves only the bounded technical property; it does not prove that an authority's internal policy or decision is substantively correct.

Required Decision-Authority Set Some acts require one authority; others can require several. A payment, for example, can require application authorization, fraud acceptance, and an attestation or device-trust decision.

Multiple required decision authorities +-----------------+ E1 Candidate C ----> Authz Authority +--------\ +-----------------+ \ \ +-----------------+ E2 \ Candidate C ----> Risk Authority +----------> [ FINALITY SINK ] --> K +-----------------+ / / +-----------------+ E3/ Candidate C ----> Attest Verifier +--------/ +-----------------+ The sink evaluates the decision-set rule for C. One valid E_i does not automatically replace another required E_j. Example conjunction: R(C) = { Authz, Fraud, Attestation } AllowFinal(C) = EvidenceValid(E_authz) AND EvidenceValid(E_fraud) AND EvidenceValid(E_attest) A profile MAY define threshold, role-class, or alternative authority rules, but this document does not define a universal policy language.

Authority-rule types beyond simple conjunction Rule examples for one Candidate Act C: 1. Conjunction: [Authz] AND [Fraud] AND [Attestation] 2. Alternative: [FraudPrimary] OR [FraudBackup] 3. Threshold: any 2 of {Risk1, Risk2, Risk3} 4. Conditional: IF amount > threshold THEN [HumanApproval] REQUIRED 5. DENY dominance: [Safety = DENY] OR [Compliance = DENY] => FINAL DENY

Decision-authority dependency graph Identity Authority | v Authorization Authority | \ | \ v v Fraud Compliance \ / \ / v Finality Sink If Fraud evaluated a different transaction/basis from Authz, both signatures can be valid while the combined decision is invalid.

Exact-Act and Decision-Basis Binding The act representation used for decision binding MUST include every parameter whose change can affect whether the act is authorized under the external decision. Canonicalization must be unambiguous for the deployment.

Wrong-act substitution Authority approves: C1 = transfer(amount=100, destination=Alice) E1 binds H(C1) Attacker attempts: C2 = transfer(amount=100000, destination=Bob) At Finality Sink: H(C1) != H(C2) | v REJECT Exact byte equality is not universally required if a profile defines an unambiguous semantic canonicalization. The security requirement is that no security-relevant semantic change be ignored by the binding.

Freshness, Currentness, and Revocation Authentic evidence can become stale. A decision made under generation G17 is not automatically applicable after a load-bearing decision basis advances to G18. t0 t1 t2 | | | | E_i issued under G17 | policy/revocation | protected | for Candidate C | advances to G18 | commit |--------------------------|--------------------------| | v verify applicability of E_i under current state If G18 invalidates E_i: reject / re-authorize / obtain new evidence. This property composes with state/policy continuity and finality-bound revocation. A deployment can use short validity, live queries, protected generations, event-driven state, challenge binding, or another method appropriate to its threat model.

Sink, Audience, and Authorized-Use Binding Exact-act binding may not be sufficient when the same evidence could be presented to a different tenant, trust domain, resource, or effectuation boundary. A profile SHOULD bind the evidence to the intended audience, sink, domain, transaction, or use context when cross-context substitution is possible. Evidence MUST NOT be treated as a general bearer execution credential merely because it verifies cryptographically.

State Machine

Expanded decision-evidence state machine +------------------+ | Candidate Act C | +--------+---------+ | v +------------------+ | Resolve R(C) | | + D_A(C) | +--------+---------+ | v +-------------------------+ | Obtain evidence / live | | decisions per authority | +------------+------------+ | v +------------------+ | Validate each E_i| +--------+---------+ | +----------+----------+ | | fail individual | results ready v | NON-EFFECTIVE v +-----------------+ | Evaluate R(C) | | DENY/UNKNOWN? | +--------+--------+ | +----------+----------+ | | fail pass | | v v NON-EFFECTIVE FINALITY SINK | currentness recheck | v PROTECTED COMMIT | v EFFECTIVE

Solution Architecture

Prepare Candidate Act Construct a canonical Candidate Act containing the security-relevant act parameters. Preparation, inference, orchestration, and ordinary upstream approval MUST NOT by themselves create the protected consequence.

Resolve Required External Authorities Determine R(C), including mandatory authorities and any approved alternative or threshold rule. The rule itself is protected policy state.

Obtain or Re-Establish External Decisions For each required authority, obtain EDE through a portable protected object or an authenticated live decision query. The mechanism MUST identify the recognized decision authority and bind or re-establish the exact Candidate Act and required context.

Remain Non-Effective The Candidate Act remains non-effective after evidence acquisition. Evidence possession alone MUST NOT create a bypass around final verification.

Verify at the Finality Sink The Finality Sink independently verifies that the complete required decision set is present and applicable, then couples successful verification to the protected commit.

End-to-End Finality Flow

End-to-end external-decision finality flow +----------------------+ | Required Authority A | +-->| decide + protect E_A | | +----------+-----------+ | | | v +-----------+ | +---------+ | Candidate |--------+-------->| E_A | | Act C | | +---------+ +-----+-----+ | | | +----------------------+ | +-->| Required Authority B | | | decide + protect E_B | | +----------+-----------+ | | | v | +---------+ | | E_B | | +----+----+ | | +-----------------------------+ | v +-------------------------+ | NON-EFFECTIVE STATE | | C + required evidence | +------------+------------+ | v +-------------------------+ | FINALITY SINK | | required set complete? | | issuers trusted? | | exact act? | | current basis? | | freshness/replay? | | sink/use applicable? | +-----------+-------------+ | pass | fail +-----------+----------+ | | v v PROTECTED COMMIT REMAIN NON-EFFECTIVE | v EFFECT K

Illustrative Pseudocode The pseudocode is non-normative. It separates Candidate Act canonicalization, protected authority-rule resolution, evidence acquisition, portable evidence verification, live queries, dependency validation, general rule evaluation, freshness/revocation handling, protected finalization, evidence consumption, multi-hop propagation, alternate-path coverage, and crash-safe recovery.

Canonicalize the Candidate Act function canonical_security_act(candidate): return CanonicalAct( subject = candidate.subject, resource = candidate.resource, operation = candidate.operation, parameters = canonical_security_parameters(candidate), destination = candidate.destination_if_security_relevant, purpose = candidate.purpose_if_required, tenant = candidate.tenant_if_required, transaction_id = candidate.transaction_id_if_required)

Resolve the Protected Authority Rule function resolve_authority_rule(candidate): rule = protected_authority_policy_lookup( canonical_security_act(candidate)) if !rule.integrity_valid: reject("authority rule integrity failure") if rule.generation != current_authority_policy_generation(): return RELOAD_RULE if rule.undefined_semantics_for( DENY, UNKNOWN, UNAVAILABLE, CHALLENGE): reject("incomplete authority composition semantics") if !dependency_graph_acyclic_or_explicitly_supported( rule.dependency_graph): reject("unsupported authority dependency cycle") return rule

Build an External Decision Request function build_decision_request(candidate, authority, sink_context): C = canonical_security_act(candidate) return { act_digest: H(C), subject: C.subject, resource: C.resource, operation: C.operation, purpose: C.purpose, transaction_id: C.transaction_id, decision_class: required_decision_class(candidate, authority), upstream_decision_context: dependency_context_for(authority, candidate), sink_or_audience: sink_context.identity_if_required, freshness_challenge: sink_context.challenge_if_required, requested_basis: current_basis_requirements(candidate, authority) }

Obtain Portable or Live External Decisions function obtain_external_decision( candidate, authority, sink_context, mode): req = build_decision_request( candidate, authority, sink_context) if mode == LIVE_QUERY: return authenticated_live_query(authority, req) if mode == PORTABLE_EVIDENCE: response = authenticated_call(authority, req) if response == NONE: return DECISION_UNAVAILABLE return response.evidence reject("unsupported decision acquisition mode")

Verify One Portable Evidence Object function verify_portable_evidence( candidate, sink, evidence, requirement, state_now): if evidence == NONE: return UNKNOWN if !issuer_matches(evidence, requirement.authority): return INVALID("wrong authority") if !verify_evidence_integrity(evidence): return INVALID("integrity/authenticity failure") C = canonical_security_act(candidate) if !act_or_allowed_class_matches(evidence, C): return INVALID("wrong candidate act") if !decision_semantics_valid(evidence): return INVALID("unknown decision semantics") if evidence.decision == DENY: return DENY if evidence.decision != ALLOW: return evidence.decision if !decision_basis_applicable(evidence, state_now): return STALE if !freshness_valid(evidence, state_now): return STALE if !audience_or_sink_valid_if_required(evidence, sink): return INVALID("wrong sink/audience") if !authorized_use_valid(evidence, C, sink): return INVALID("use constraints violated") if !replay_rule_satisfied(evidence, C, sink): return INVALID("replay/use violation") if evidence_superseded(evidence, state_now): return STALE return ALLOW

Verify a Live External Decision function verify_live_decision(candidate, sink, authority): C = canonical_security_act(candidate) challenge = fresh_sink_challenge() response = authenticated_decision_query( authority, act_digest = H(C), sink = sink.identity_if_required, challenge = challenge, transaction_id = C.transaction_id) if !channel_peer_is(response.channel, authority): return INVALID("wrong authority") if response.challenge != challenge: return INVALID("freshness challenge mismatch") if response.act_digest != H(C): return INVALID("wrong candidate act") if response.decision == DENY: return DENY if response.decision != ALLOW: return response.decision if !response.basis_current(current_security_state()): return STALE return ALLOW

Validate Authority Dependencies function validate_authority_dependencies( candidate, rule, evidence_map): order = topological_order(rule.dependency_graph) for authority in order: deps = dependencies_of(authority) for dep in deps: if evidence_map[dep] != ALLOW: return INVALID( "dependency not satisfied", dep) if !decision_context_binds_dependency( authority_evidence=evidence_map.raw[authority], dependency_evidence=evidence_map.raw[dep], candidate=candidate): return INVALID( "authority evaluated inconsistent basis") return VALID

Evaluate the General Authority Rule function evaluate_authority_rule(rule, decision_map): # DENY-dominant authorities first. for authority in rule.deny_override_authorities: if decision_map[authority] == DENY: return DENY for mandatory in rule.mandatory: if decision_map[mandatory] != ALLOW: return decision_map[mandatory] for group in rule.any_of_groups: if count(ALLOW in group) < 1: return DENY_OR_UNKNOWN_BY_POLICY(group) for threshold in rule.threshold_groups: if count(ALLOW in threshold.authorities) < threshold.k: return DENY_OR_UNKNOWN_BY_POLICY(threshold) for conditional in rule.conditionals: if conditional.predicate(candidate): if decision_map[conditional.authority] != ALLOW: return decision_map[conditional.authority] return ALLOW

Verify the Complete Required Decision Set function verify_required_decision_set( candidate, sink, evidence_set): rule = resolve_authority_rule(candidate) decision_map = {} raw_map = {} for requirement in rule.all_requirements: evidence = select_evidence( evidence_set, authority=requirement.authority, decision_class=requirement.decision_class) result = verify_portable_evidence( candidate, sink, evidence, requirement, current_security_state()) decision_map[requirement.authority] = result raw_map[requirement.authority] = evidence decision_map.raw = raw_map if validate_authority_dependencies( candidate, rule, decision_map) != VALID: reject("authority dependency failure") result = evaluate_authority_rule( rule, decision_map) if result != ALLOW: reject_or_reauthorize( "required authority rule not satisfied", result) return { rule: rule, decisions: decision_map, generation: current_decision_state_generation(candidate) }

Refresh Stale or Superseded Decisions function refresh_stale_decisions( candidate, sink, verification_result): refreshed = {} for authority, result in verification_result.decisions: if result in {STALE, UNKNOWN, UNAVAILABLE}: refreshed[authority] = obtain_external_decision( candidate, authority, sink.context, mode=preferred_mode(authority)) else: refreshed[authority] = verification_result.decisions.raw[authority] return refreshed

Protected Finalization function finalize(candidate, evidence_set): begin_protected_finality_section() sink = current_finality_sink() if !candidate_integrity_valid(candidate): reject("invalid candidate") if candidate.expired: reject("candidate expired") verified = verify_required_decision_set( candidate, sink, evidence_set) observed_generation = verified.generation if !effectuation_path_authorized(candidate, sink): reject("unmediated effectuation path") atomic { current = current_security_state() assert current_decision_state_generation(candidate) == observed_generation assert required_decision_set_still_applicable( candidate, verified.decisions.raw, current) assert protected_authority_rule_still_same( candidate, verified.rule) assert policy_still_allows(candidate, current) assert revocation_state_allows(candidate, current) assert trust_state_allows(candidate, current) consume_once_if_required( candidate.execution_authority) consume_or_mark_evidence_if_required( candidate, verified.decisions.raw) commit_protected_effect(candidate) } return EFFECT_COMMITTED

Evidence Replay and Consumption State function consume_or_mark_evidence_if_required( candidate, evidence_map): for authority, evidence in evidence_map: rule = replay_policy_for( authority, evidence, candidate) if rule == REUSABLE: continue if rule == SINGLE_USE: protected_consume_once(evidence.id) continue if rule == TRANSACTION_BOUND: protected_mark_used( evidence.id, candidate.transaction_id) continue if rule == SINK_BOUND: protected_mark_use( evidence.id, current_finality_sink().identity) continue reject("undefined evidence replay semantics")

Preserve Decision Context Across Multi-Hop Systems function forward_candidate( candidate, next_hop, verified_context): envelope = { candidate: candidate, act_digest: H(canonical_security_act(candidate)), authority_rule_id: verified_context.rule.id, decision_generation: verified_context.generation, evidence_references: scoped_references( verified_context.decisions.raw) } return authenticated_forward( next_hop, envelope) # Downstream hops MUST NOT assume the references remain current. # The Finality Sink re-establishes applicability before effect.

Verify Required-Decision Coverage Across Effectuation Paths function verify_decision_path_coverage( consequence, path_inventory, required_authority_rule): for path in paths_capable_of( consequence, path_inventory): if path.crosses_sink_that_enforces( required_authority_rule): continue if path.enforces_equivalent_decision_invariant: continue return CoverageFailure( reason="required-decision bypass path", witness=path) return COVERAGE_VALID

Crash-Safe Recovery function recover(candidate_id): state = protected_commit_state(candidate_id) if state == EFFECTIVE: return DO_NOT_REPLAY if state == COMMITTING: outcome = resolve_atomic_commit(candidate_id) if outcome == EFFECT_COMMITTED: return DO_NOT_REPLAY return REVALIDATE_ALL_REQUIRED_DECISIONS if state == PENDING: return REVALIDATE_ALL_REQUIRED_DECISIONS return FAIL_CLOSED

Live Query Versus Portable Evidence Portable evidence is useful for asynchronous workflows, disconnected verification, multi-hop systems, later audit, and independently verifiable provenance. A live authenticated decision query can provide stronger currentness in some deployments and can avoid replay or portability concerns. This architecture does not prefer one universally. The requirement is semantic: independently establish the required external decision for the exact act under current applicability rules at or immediately before the protected effect.

Live query versus portable evidence Portable evidence: Authority -> signed E_i -> queue/store -> Finality Sink | independently verifiable asynchronous / multi-hop replay rules required Live query: Finality Sink -- fresh challenge --> Authority Finality Sink <-- bound decision ---- Authority | strong currentness authority availability required Both can satisfy the architecture if semantic requirements match.

Live query must still bind the exact act Fresh TLS channel alone is insufficient: Sink -------- authenticated --------> Authority asks: "may user act?" | v ALLOW But pending effect is: transfer(amount=100000, account=B) Required live semantics: peer identity + exact act digest / allowed class + decision + freshness challenge + current basis + sink/use constraints if required

SCITT Transparency and Offline Verification A SCITT Signed Statement or Receipt can strengthen provenance and transparency of Decision Evidence, particularly where later independent verification is important. A profile can require registration before effectuation or allow registration after effectuation for accountability.

Audit-only evidence versus prevention Audit / accountability path: Candidate C ---> EFFECT K ---> create/register receipt | +---- effect already occurred Prevention path: Candidate C | v obtain / resolve required decision evidence | v FINALITY SINK verifies evidence | v protected commit | v EFFECT K The two flows can coexist. The distinction is whether evidence verification is a prerequisite to effectuation.

RATS-Based Decision Evidence Where a protected act requires an acceptable workload, device, firmware, or execution environment state, an Attestation Result can serve as EDE from a recognized Verifier. The profile must determine whether the Attestation Result is sufficiently fresh, whether it applies to the workload performing or requesting C, and whether any change in trust state requires re-appraisal before effectuation.

Multi-Hop and WIMSE Composition In a multi-service chain, the component that first obtains a decision may not control the final consequence. EDE therefore needs either to travel with the transaction, be re-resolvable from a protected identifier, or be re-established by the final component.

Decision dependency across a multi-hop chain External Decision Authority | | E_A / resolvable decision reference v Workload A | | WIMSE / Txn-Token / service context v Workload B | v Queue / Worker | v +------------------+ | FINALITY SINK | | independently | | establish E_A | +--------+---------+ | v EFFECT K Merely propagating identity context does not automatically prove that a particular required authority issued an applicable decision, while a portable EDE object does not replace workload authentication. The two properties are complementary.

Decision context can become stale across asynchronous hops A_authz issues E under G17 | v Service A -> Queue -> Service B -> Worker C -> Finality Sink ^ | policy becomes G18 Forwarded E[G17] remains authentic but may no longer be applicable at final effect.

Alternate-Path Resistance Perfect Decision Evidence is not preventive if a second path can create K without verifying it. A prevention profile therefore composes with consequence-path completeness: every route capable of creating the protected consequence must either cross a Finality Sink that verifies the required decision set or preserve an equivalent invariant.

Required-decision verification bypass Protected path: C -> collect E1,E2 -> Finality Sink -> EFFECT ^ | rule R(C) enforced Alternate path: C -> admin / queue / direct storage / recovery ------> EFFECT If alternate path can cause the same consequence without R(C), evidence verification on the protected path is not prevention.

Attack Analysis

Fabricated "ALLOW" A compromised intermediary claims that authority A returned ALLOW but presents no acceptable EDE. The Finality Sink rejects because A is required and RequiredEvidenceSatisfied is false.

Wrong-Act Substitution EDE was issued for C1 and is presented with C2. Exact-act binding fails.

Evidence Replay Authentic evidence from a prior act or transaction is replayed. Freshness, transaction/sink binding, consume-once semantics, or current-state rules reject the replay according to the profile.

Partial Authority-Set Attack The attacker presents authorization-service approval but omits a mandatory fraud or attestation decision. The authority-set rule fails even though the presented evidence is valid.

Suppressed DENY or Challenge An intermediary suppresses a negative result and presents only positive evidence from another authority. The sink evaluates the complete required authority rule rather than trusting the intermediary's aggregate statement.

Stale but Authentic Decision Evidence remains cryptographically valid after the relevant policy or revocation generation changes. Current applicability fails and the act is re-authorized or rejected.

Cross-Tenant or Cross-Sink Substitution Evidence issued for one tenant, jurisdiction, resource, or effectuation sink is presented in another. Audience/sink/domain or authorized-use binding rejects the substitution where the deployment requires such binding.

Audit Artifact Presented as Authority A receipt proves that a statement was registered or logged, but the statement does not semantically authorize the act or was registered after effectuation. The Finality Sink rejects because provenance alone does not satisfy DecisionAllows and applicability.

High-Assurance Enforcement

Deployment Patterns

Finality Sink Performs Live Decision Query The sink contacts the required authority immediately before effectuation. This can minimize stale-state risk and avoid portable bearer-like evidence.

Portable Signed Decision Evidence The authority issues a signed Permit, statement, Attestation Result, or other protected object that the sink verifies later. This is useful for asynchronous and multi-hop workflows.

Protected Decision Reference The upstream component carries only a protected identifier or digest, and the sink retrieves or reconstructs the authoritative decision from a protected service.

Hybrid Evidence plus Current-State Check The sink verifies signed issuance-time evidence and separately checks current revocation, policy generation, or risk state before commit.

Performance and Availability Requiring synchronous calls to several authorities on every hot-path operation can be expensive and can reduce availability. Portable evidence, protected local status roots, mirrored generations, cached authority metadata, and threshold rules can reduce hot-path cost when their staleness and replay semantics are explicit. A performance optimization MUST NOT silently convert a prevention profile into an audit-only profile. Deployments SHOULD document decision latency, evidence-verification latency, cache lifetime, propagation delay, and the maximum interval during which an otherwise authentic decision can remain accepted after a load-bearing state change.

Complementary Industrial Alignment Microsoft Entra Continuous Access Evaluation demonstrates event-driven enforcement of critical identity and risk changes by relying applications and resource providers . Amazon Verified Permissions/Cedar provides externalized authorization decisions over principal, action, resource, and context . Google Cloud IAM deny policies provide centrally managed prohibitions over principals and permissions . NVIDIA attestation and Arm CCA provide protected-compute and attestation mechanisms that can supply trust inputs or host protected verification/enforcement components . These systems are cited as industrial alignment or integration points only. This document does not assert that any named product is insecure, incomplete, vulnerable, non-conforming, or required to implement this architecture. A particular deployment may already provide some or all of the proposed invariant.

Required Classes of Test Vectors A concrete profile or implementation SHOULD test at least:

all required authorities issue applicable ALLOW decisions for exact C: succeed;
one mandatory authority missing: reject;
one authority returns DENY: reject according to the authority-set rule;
evidence issuer does not match required authority: reject;
evidence for C1 presented with C2: reject;
evidence replayed outside permitted transaction or use: reject;
policy/revocation generation changed after issuance: re-authorize or reject;
evidence presented to wrong tenant/sink where sink binding is required: reject;
SCITT receipt valid but underlying statement does not authorize C: reject;
Attestation Result valid but not applicable to the acting workload/current state: reject;
threshold rule satisfied by allowed authority combination: succeed;
threshold rule not satisfied: reject;
live-query challenge mismatch: reject;
evidence unavailable under a fail-closed prevention profile: remain non-effective;
alternate path reaches effect without evidence verification: prevention profile fails;
audit record created only after effect: classify as audit/accountability, not prevention.

Implementations SHOULD include negative tests for: valid evidence from the wrong authority; valid evidence bound to the wrong act; threshold rules with insufficient ALLOW decisions; DENY-dominant authorities; UNKNOWN and timeout handling; stale basis generations; dependency graphs evaluated over inconsistent upstream context; replay at another sink or transaction; a live query with fresh TLS but no exact-act binding; and alternate effectuation paths that bypass the required-authority rule.

Questions to the IETF Community Criticism, corrections, counterexamples, operational experience, prior-art pointers, evidence that existing IETF mechanisms already provide an equivalent invariant, and recommendations to narrow, merge, or stop the work are explicitly invited. Negative answers are useful outcomes.

Does together with already provide the full proposed invariant when the actual effectuation boundary verifies the Permit before effectuation?
If not, what exact residual property remains: authority provenance, exact-act binding, currentness, sink binding, required-decision-set semantics, or effectuation coupling?
Should this work therefore be a BCP or architecture/problem statement rather than a new evidence format?
Is the term External Decision Evidence useful, or does existing IETF terminology already cover the same architectural role?
When a Resource Server directly queries an authoritative third party over an authenticated channel immediately before effectuation, is portable evidence unnecessary?
When does a live authenticated query provide stronger semantics than a portable signed decision object?
Should portable Decision Evidence normally be audience/sink bound, or is exact-act binding sufficient for common deployments?
How should policy-generation or revocation changes invalidate otherwise authentic Decision Evidence?
How should several required authorities be represented without defining a universal policy language?
Are threshold or quorum decision rules appropriate in an IETF security-architecture document?
How should an implementation distinguish Decision Evidence from bearer execution authority?
What canonicalization rules are necessary to prevent evidence from being rebound to a semantically different act?
Can SCITT receipts provide useful transparency and accountability while remaining outside the hot path?
What is the correct relationship between SCITT registration proof and execution-time authorization?
For RATS, when is an Attestation Result sufficient as a required external decision, and when must it be rebound to a concrete Candidate Act?
How should WIMSE identity and delegation context be associated with evidence without duplicating WIMSE credential formats?
Which existing commercial or standards-based systems already guarantee this invariant in full?
What counterexample would falsify or materially narrow the need for this architecture?
Which deployment classes inherently provide only auditability or mitigation rather than prevention?
Which venue is most appropriate for further discussion: OAuth, WIMSE, SCITT, RATS, DISPATCH, SAAG, or another group?

Potential IETF Discussion Venues and Scope Boundaries

OAuth OAuth is directly relevant because Token Introspection, Transaction Tokens, and current agent/delegation work address authorization context and decisions. This document should not presume that OAuth owns non-OAuth effectuation semantics.

WIMSE WIMSE is highly relevant to distributed workload identity and authorization context, and current authorization-evidence work is discussed in that community.

SCITT SCITT is relevant to signed statements, transparency, registration, and receipts. A decision-evidence profile can compose with SCITT without turning every SCITT statement into execution authority.

RATS RATS is relevant where the required external decision is an attestation or trust appraisal, or where the Finality Sink itself requires attested protection.

DISPATCH DISPATCH can be useful for routing if the work cuts across OAuth, WIMSE, SCITT, RATS, and general security architecture without a clear single owner.

SAAG SAAG is useful for broad Security Area architectural criticism. It is not a Working Group that adopts documents.

No Presumed Home This document does not claim that any named group should adopt the work. The preferred sequence is overlap review, criticism, validation of any residual gap, and routing only if a distinct interoperable work item remains justified.

Relationship to Other Execution-Finality Internet-Drafts This document isolates third-party decision binding rather than repeating the broader execution-finality architecture.

The protocol-layer draft defines the broad Candidate Act to Non-Effective State to protected validation to Finality Sink architecture.
The agentic draft applies execution finality to AI tool dispatch.
The hardware-rooted draft discusses protected enforcement for high-consequence infrastructure.
The RATS/attestation-bound draft connects trusted workload state to consequential authority.
The state/policy-continuity draft asks whether the earlier decision basis remains applicable before effectuation.
The finality-bound-revocation draft asks whether withdrawn authority can survive to protected commit.
The consequence-path-completeness draft asks whether the effect can bypass enforcement entirely.
The purpose-execution-finality draft addresses purpose/capability laundering and cross-domain data reuse.
The AI-interoperability draft applies bounded finality to third-party AI/device interoperability.
This document asks whether a required independent decision can be independently established as real, applicable, and load-bearing at the final effect.

State continuity: Is the earlier decision basis still applicable? Revocation finality: Has authority been withdrawn before effectuation? Consequence-path completeness: Can the effect avoid enforcement entirely? Third-party decision binding: Can the Finality Sink independently establish that the REQUIRED external authority actually issued the applicable decision for this exact act? Related documents include , , , , , , , , and .

Public Implementations and Companion Engineering Material The following repositories provide related execution-finality engineering material. They are not represented as standardized External Decision Evidence implementations unless the relevant code and profile explicitly provide that property.

Execution-Finality Architecture for Machine-Generated Acts: architectural background for Candidate Acts, protected validation, evidence, and Finality Sinks.
Hardened Challenge-Bound Execution Finality for AI Interoperability: runnable challenge binding, exact-effect binding, policy/epoch/revocation checks, replay protection, and protected finality at selected sinks.

The companion materials are and . A future implementation of the exact EDE profile described here should be identified as such only after its issuer, act, currentness, authority-set, and sink-binding semantics are verified.

Security Considerations Security depends simultaneously on correct required-authority policy, evidence integrity, exact-act applicability, current-state handling, Finality Sink integrity, and non-bypassable effectuation. Strong cryptography on an irrelevant or stale decision does not create authorization.

Compromised Intermediary The Finality Sink MUST NOT rely on an untrusted intermediary's assertion that a required external decision occurred. It must verify EDE or perform an authenticated equivalent query.

Compromised Requester or Agent A requester may present selectively chosen evidence, omit negative results, or attempt to construct a Candidate Act after decision issuance. The sink reconstructs the exact act and required authority set independently.

Decision-Authority Compromise If a required EDA is compromised, it can issue malicious ALLOW decisions. Higher- assurance profiles can use independent authorities, threshold rules, transparency, separation of duties, or narrower trust scopes. The base model does not claim to detect a fully compromised trusted authority.

Evidence Forgery Evidence authentication keys, algorithms, trust roots, and verification policy must be appropriate to the deployment. Unknown or untrusted issuers MUST NOT satisfy a required authority rule.

Wrong-Authority Substitution A valid signature from authority B does not satisfy a requirement for authority A merely because both issue syntactically similar evidence.

Exact-Act Substitution Security-relevant act parameters must be covered by the decision binding. Canonicalization ambiguities can otherwise permit semantic substitution.

Evidence Replay and Bearerization Evidence can become a bearer-like authority if it is reusable without appropriate act, sink, transaction, freshness, or consumption constraints. Profiles MUST define replay semantics explicitly.

Stale Decision Basis An authentic decision can become inapplicable after policy, risk, reference, resource, account, or trust state changes. Currentness is distinct from signature validity.

Revocation After Evidence Issuance If revocation is load-bearing, the Finality Sink must verify current revocation state or otherwise establish that the evidence remains applicable before commit.

Required Evidence Omission The required-authority rule must be protected. An attacker MUST NOT satisfy a multi-authority policy by presenting only the easiest positive decision.

Conflicting Authorities and Threshold Rules Profiles using multiple authorities must define how DENY, CHALLENGE, UNKNOWN, timeout, and conflicting decisions compose. Ambiguity SHOULD fail closed for prevention profiles.

Audience, Sink, Tenant, and Jurisdiction Confusion Evidence valid for one context can be unsafe in another. Profiles should bind or re-establish these dimensions wherever cross-context reuse can change authorization.

Canonicalization The representation hashed or signed must correspond to the semantics evaluated by the EDA and effected by the sink. Alternate encodings, default values, omitted fields, parameter ordering, external references, and dynamically resolved values require explicit treatment.

TOCTOU Between Evidence Verification and Commit A successful verification followed by an unprotected delay reintroduces a race. The final current-state check and protected commit require atomicity, generation locking, compare-and-swap, transaction serialization, or an equivalent invariant where concurrent state changes are load-bearing.

Evidence Cache Rollback An attacker may restore an older positive decision cache. Protected generations, authenticated roots, monotonic state, or equivalent anti-rollback mechanisms are needed where cached evidence is accepted.

Lost or Reordered Decision Events Push-based state or revocation updates require authenticated ordering, gap detection, or equivalent rules. Loss of a negative event MUST NOT silently preserve a prevention claim that requires current state.

Alternate Effectuation Path Every technical path capable of producing the protected consequence must preserve the required-decision invariant. An alternate API, queue, direct storage path, administrative interface, device path, or recovery mechanism can otherwise bypass perfect evidence verification.

Fail-Open Behavior Decision-authority unavailability creates availability pressure. For an operation whose prevention profile requires the authority, "decision unavailable" MUST NOT silently become ALLOW. Lower-assurance fallback modes must be explicit.

Denial of Service Attackers can target EDAs, evidence retrieval, transparency services, or status channels to block effectuation. Replication and caching can improve availability, but not by silently weakening required currentness or authority-set semantics.

Audit Receipt Confused with Execution Authority A receipt proving that a statement was registered, logged, or witnessed does not by itself prove that the statement authorizes C or that the protected effect was conditional on it.

SCITT Registration Is Not Semantic Correctness SCITT transparency strengthens provenance and accountability. The Finality Sink still needs application semantics establishing that the underlying statement is from the required authority and applies to the pending Candidate Act.

Verifier Compromise Where the EDA is a RATS Verifier or another appraisal component, compromise can produce malicious positive results. The trust model and any multi-verifier or threshold controls must be explicit.

Crash Consistency A crash between required-evidence verification, execution-authority consumption, and protected commit must not create a replay or bypass. Transactional or idempotent recovery may be required.

Evidence Retention Long-lived evidence can improve auditability but increase privacy, correlation, and key- compromise exposure. Retention should match the security and accountability objective.

Out-of-Scope Failures The architecture does not infer human intent, guarantee that an EDA's policy is morally or legally correct, defeat compromise of every trust root, prevent physical subversion outside the hardware model, or control consequences outside the declared effectuation domain.

Privacy Considerations Decision Evidence can reveal identity, transaction details, risk classifications, account status, purpose, resource relationships, device posture, jurisdiction, or operational timing. Profiles SHOULD minimize evidence contents and SHOULD avoid exposing raw decision-basis inputs when a scoped decision, digest, selective-disclosure statement, or protected reference is sufficient. Stable evidence identifiers can become correlators across services. Audience-scoped identifiers, pairwise references, local verification, and bounded retention can reduce linkability where compatible with the security objective.

Criticism, Corrections, and Review Invited This document is intentionally presented for adversarial technical review. Reviewers are invited to identify incorrect assumptions, existing standards or products that already provide the full property, deployment cases where the proposed abstraction is unnecessary, evidence formats that already encode every required semantic, unmodeled bypass paths, privacy costs, latency costs, or terminology that conflicts with established IETF usage. The strongest requested counterexample is a concrete deployment in which existing authorization-evidence, SCITT, OAuth, RATS, WIMSE, or another standardized mechanism already guarantees that a required independent decision for the exact act is both independently verifiable and technically mandatory at the non-bypassable effectuation boundary. Such evidence should narrow, merge, or correct this proposal rather than be treated as opposition.

IANA Considerations This document has no IANA actions.

Conclusion A distributed system can contain excellent policy engines, signed evidence, receipts, attestation results, and audit trails while still leaving one question unresolved: did the actual protected effect technically depend on the required independent decision for this exact act? "Authority Y was checked" != "Finality Sink independently established Y's applicable decision for exact act C" For the prevention profile: Required decision missing or inapplicable ==> Candidate remains non-effective Existing mechanisms that already enforce this relationship already satisfy the core invariant. The purpose of this document is to make the decision-to-effect relationship explicit, testable, composable with existing IETF mechanisms, and open to correction by the community. A useful implementation should be able to explain not merely that "authorization failed" but which authority requirement was unsatisfied, which evidence predicate failed, whether the failure was exact-act binding, freshness, currentness, replay, dependency consistency, rule composition, or effectuation-path coverage, and under which protected generation the decision was evaluated.