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

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

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

1.2. 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 [RFC7662]. 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 [MUNOZ-EVIDENCE] 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 [MUNOZ-SCITT] 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 [RFC9943] provides an architecture for signed statements, transparency, registration, and receipts. RATS [RFC9334] provides a mature architecture for Evidence, Verifiers, Attestation Results, Reference Values, and appraisal. HTTP Message Signatures [RFC9421] provide integrity and authenticity over selected HTTP message components. Transaction Tokens [TXN-TOKENS] maintain and propagate identity and authorization context through trusted-domain call chains. WIMSE [WIMSE-ARCH] 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.¶

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

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

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

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

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

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

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

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

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

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

8.1. OAuth Token Introspection

RFC 7662 defines a method for a protected resource to query an OAuth authorization server about token active state and metadata [RFC7662]. 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.¶

8.2. Signed Authorization Evidence and the Munoz Permit

[MUNOZ-EVIDENCE] 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. [MUNOZ-SCITT] 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.¶

8.3. SCITT

RFC 9943 defines an architecture for signed statements, transparency, registration, and verifiable receipts [RFC9943]. 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.¶

8.4. RATS and Attestation Results

RATS defines Evidence, Verifiers, Attestation Results, Endorsements, Reference Values, and Relying Party appraisal [RFC9334]. 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.¶

8.5. HTTP Message Signatures

RFC 9421 provides integrity and authenticity over selected HTTP message components [RFC9421]. 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.¶

8.6. OAuth Transaction Tokens

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

8.7. WIMSE

WIMSE addresses workload identity and security context across multi-system and multi-hop environments [WIMSE-ARCH]. 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.¶

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

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

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

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

12.2. Candidate and Authority Model

Let 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

12.3. Abstract Evidence Semantics

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

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

12.5. General Authority-Composition Rule

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

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

12.7. Authority Dependency Graph

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

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

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

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

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

12.12. 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)

12.13. Verification-to-Commit Serialization

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

12.14. 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)

12.15. Expanded Bounded Prevention Proof

Assume: (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.¶

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

18.2. Resolve Required External Authorities

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

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

18.4. Remain Non-Effective

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

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

18.6. End-to-End 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

19.1. 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)

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

19.3. 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)
    }

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

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

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

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

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

19.9. 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)
    }

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

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

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

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

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

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

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

25.2. Wrong-Act Substitution

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

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

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

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

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

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

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

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

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

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

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

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

32.2. WIMSE

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

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

32.4. RATS

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

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

32.6. SAAG

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

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

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

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

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

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

35.5. Wrong-Authority Substitution

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

35.6. Exact-Act Substitution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35.24. Evidence Retention

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

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