Trust Me, I Checked: Verifiable Third-Party Decision Binding at the Execution-Finality Boundary
draft-das-third-party-decision-binding-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
An Architecture for Technical Enforcement for GDPR and the EU AI Act in Critical AI Systems
The Internet Solved Communication. It Never Solved Authority. |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-third-party-decision-binding-00
Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 16 September 2026
Expires: 20 March 2027
Trust Me, I Checked: Verifiable Third-Party Decision Binding at the
Execution-Finality Boundary
draft-das-third-party-decision-binding-00
Abstract
High-consequence distributed systems frequently allow one component
to act based on a decision produced by another component, such as an
authorization server, policy engine, risk service, attestation
Verifier, compliance service, workload-identity authority, or safety
controller. The vulnerability is not limited to forged credentials:
a compromised or incorrectly designed intermediary can claim that a
required third-party check succeeded, replay an earlier decision,
substitute evidence from a different act or context, suppress a
required DENY, or retain evidence only for audit while the protected
effect remains technically independent of that evidence. The issue
deserves high attention where the downstream consequence is
financial, administrative, privacy-sensitive, safety-relevant,
infrastructure-changing, or otherwise difficult to reverse.
Existing mechanisms solve important parts of this problem. OAuth
Token Introspection [RFC7662] lets a protected resource query token
state; HTTP Message Signatures [RFC9421] provide integrity and
authenticity for selected HTTP message components; RATS [RFC9334]
provides Evidence, Verifiers, and Attestation Results; Transaction
Tokens [TXN-TOKENS] propagate identity and authorization context
through trusted call chains; SCITT [RFC9943] provides signed
statements, transparency, and verifiable receipts; and current
authorization- evidence work [MUNOZ-EVIDENCE] [MUNOZ-SCITT] defines
signed pre-execution Permits bound to canonical request material.
Where one of these mechanisms is verified by the actual non-
bypassable effectuation boundary and already proves the required
decision for the exact act, current context, and authorized use, that
deployment can already satisfy the property described here.
The residual gap arises only where the consequential component
receives an upstream claim such as "the external check passed", where
authentic evidence is bound to the wrong act, authority, tenant,
purpose, generation, or sink, where valid evidence has become stale
or replayable, where only a subset of required authorities is
represented, or where evidence exists but is not a load-bearing
prerequisite of effectuation. This document introduces an
Das Expires 20 March 2027 [Page 1]
Internet-Draft Third-Party Decision Binding September 2026
architectural role called External Decision Evidence (EDE). EDE is
not a new wire format: an existing Permit, SCITT statement or
receipt, Attestation Result, live authenticated decision response, or
other protected result can instantiate EDE when its semantics satisfy
the deployment profile.
The proposed invariant is that a Candidate Act remains non-effective
until the Finality Sink independently establishes that every required
external decision authority issued an applicable decision for the
concrete act, under the required decision basis and current state,
with freshness, audience or sink binding, and authorized-use
semantics appropriate to the deployment. Prevention is claimed only
when the protected consequence cannot occur without successful
verification of the required evidence and alternate effectuation
paths cannot bypass that verification. Otherwise the mechanism
provides auditability, accountability, detection, or mitigation
rather than the same prevention guarantee.
The model is intended to complement, not criticize or replace, OAuth,
WIMSE, SCITT, RATS, externalized policy systems such as Amazon
Verified Permissions/Cedar, continuous-access systems such as
Microsoft Entra Continuous Access Evaluation, Google Cloud IAM
controls, and protected-compute technologies such as NVIDIA
attestation and Arm CCA. The proposed delta is not the invention of
signatures, authorization evidence, receipts, or attestation results;
it is the effectuation-time requirement that independently verifiable
required decisions become load-bearing for the exact protected act.
Criticism, corrections, counterexamples, implementation experience,
prior-art pointers, and evidence that existing mechanisms already
provide the full invariant are explicitly invited.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 March 2027.
Das Expires 20 March 2027 [Page 2]
Internet-Draft Third-Party Decision Binding September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Vulnerability: "Trust Me, I Checked" . . . . . . . . . . 6
1.2. Existing Solutions Already Address Important Parts . . . 7
1.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 8
1.4. What This Architecture Introduces . . . . . . . . . . . . 9
2. Conventions and Requirements Language . . . . . . . . . . . . 9
3. Direct Question: What Threat Does This Architecture Solve? . 9
4. Motivating Scenario: Fabricated or Misbound External
Approval . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Decision Provenance Is Not Decision Applicability . . . . 11
5.2. Evidence Is Not Execution Authority . . . . . . . . . . . 11
5.3. Audit Is Not Prevention . . . . . . . . . . . . . . . . . 11
6. Threat Model and Assurance Scope . . . . . . . . . . . . . . 11
6.1. Adversary Capabilities . . . . . . . . . . . . . . . . . 11
6.2. Threat Severity and Applicability . . . . . . . . . . . . 12
6.3. Baseline Third-Party-Decision Profile . . . . . . . . . . 12
6.4. High-Assurance Third-Party-Decision Profile . . . . . . . 12
6.5. Trusted Roots and Limits . . . . . . . . . . . . . . . . 12
7. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 13
8. Existing Mechanisms and the Proposed Delta . . . . . . . . . 13
8.1. OAuth Token Introspection . . . . . . . . . . . . . . . . 13
8.2. Signed Authorization Evidence and the Munoz Permit . . . 13
8.3. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. RATS and Attestation Results . . . . . . . . . . . . . . 14
8.5. HTTP Message Signatures . . . . . . . . . . . . . . . . . 14
8.6. OAuth Transaction Tokens . . . . . . . . . . . . . . . . 14
8.7. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.8. What Is New in This Document . . . . . . . . . . . . . . 15
9. Prevention, Mitigation, and Auditability . . . . . . . . . . 15
9.1. Prevention Profile . . . . . . . . . . . . . . . . . . . 15
9.2. Mitigation or Accountability Profile . . . . . . . . . . 16
Das Expires 20 March 2027 [Page 3]
Internet-Draft Third-Party Decision Binding September 2026
10. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. External Decision Evidence Model . . . . . . . . . . . . . . 17
12. Formal Mathematical Model . . . . . . . . . . . . . . . . . . 18
12.1. Bounded Prevention Argument . . . . . . . . . . . . . . 19
12.2. Candidate and Authority Model . . . . . . . . . . . . . 19
12.3. Abstract Evidence Semantics . . . . . . . . . . . . . . 19
12.4. Evidence Validity Predicate . . . . . . . . . . . . . . 20
12.5. General Authority-Composition Rule . . . . . . . . . . . 20
12.6. Authority-Rule Evaluation . . . . . . . . . . . . . . . 21
12.7. Authority Dependency Graph . . . . . . . . . . . . . . . 22
12.8. Exact-Act Binding . . . . . . . . . . . . . . . . . . . 23
12.9. Decision-Basis Currentness . . . . . . . . . . . . . . . 23
12.10. Replay and Non-Bearer Semantics . . . . . . . . . . . . 23
12.11. Live-Query Equivalence . . . . . . . . . . . . . . . . . 24
12.12. Required Decision Satisfaction . . . . . . . . . . . . . 24
12.13. Verification-to-Commit Serialization . . . . . . . . . . 24
12.14. Strict Effectuation Invariant . . . . . . . . . . . . . 25
12.15. Expanded Bounded Prevention Proof . . . . . . . . . . . 25
13. Required Decision-Authority Set . . . . . . . . . . . . . . . 26
14. Exact-Act and Decision-Basis Binding . . . . . . . . . . . . 27
15. Freshness, Currentness, and Revocation . . . . . . . . . . . 29
16. Sink, Audience, and Authorized-Use Binding . . . . . . . . . 30
17. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 30
18. Solution Architecture . . . . . . . . . . . . . . . . . . . . 33
18.1. Prepare Candidate Act . . . . . . . . . . . . . . . . . 33
18.2. Resolve Required External Authorities . . . . . . . . . 33
18.3. Obtain or Re-Establish External Decisions . . . . . . . 33
18.4. Remain Non-Effective . . . . . . . . . . . . . . . . . . 33
18.5. Verify at the Finality Sink . . . . . . . . . . . . . . 33
18.6. End-to-End Finality Flow . . . . . . . . . . . . . . . . 33
19. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 35
19.1. Canonicalize the Candidate Act . . . . . . . . . . . . . 35
19.2. Resolve the Protected Authority Rule . . . . . . . . . . 35
19.3. Build an External Decision Request . . . . . . . . . . . 35
19.4. Obtain Portable or Live External Decisions . . . . . . . 36
19.5. Verify One Portable Evidence Object . . . . . . . . . . 36
19.6. Verify a Live External Decision . . . . . . . . . . . . 38
19.7. Validate Authority Dependencies . . . . . . . . . . . . 38
19.8. Evaluate the General Authority Rule . . . . . . . . . . 39
19.9. Verify the Complete Required Decision Set . . . . . . . 40
19.10. Refresh Stale or Superseded Decisions . . . . . . . . . 41
19.11. Protected Finalization . . . . . . . . . . . . . . . . . 41
19.12. Evidence Replay and Consumption State . . . . . . . . . 42
19.13. Preserve Decision Context Across Multi-Hop Systems . . . 43
19.14. Verify Required-Decision Coverage Across Effectuation
Paths . . . . . . . . . . . . . . . . . . . . . . . . . 44
19.15. Crash-Safe Recovery . . . . . . . . . . . . . . . . . . 44
20. Live Query Versus Portable Evidence . . . . . . . . . . . . . 45
Das Expires 20 March 2027 [Page 4]
Internet-Draft Third-Party Decision Binding September 2026
21. SCITT Transparency and Offline Verification . . . . . . . . . 47
22. RATS-Based Decision Evidence . . . . . . . . . . . . . . . . 47
23. Multi-Hop and WIMSE Composition . . . . . . . . . . . . . . . 48
24. Alternate-Path Resistance . . . . . . . . . . . . . . . . . . 49
25. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 49
25.1. Fabricated "ALLOW" . . . . . . . . . . . . . . . . . . . 49
25.2. Wrong-Act Substitution . . . . . . . . . . . . . . . . . 49
25.3. Evidence Replay . . . . . . . . . . . . . . . . . . . . 49
25.4. Partial Authority-Set Attack . . . . . . . . . . . . . . 50
25.5. Suppressed DENY or Challenge . . . . . . . . . . . . . . 50
25.6. Stale but Authentic Decision . . . . . . . . . . . . . . 50
25.7. Cross-Tenant or Cross-Sink Substitution . . . . . . . . 50
25.8. Audit Artifact Presented as Authority . . . . . . . . . 50
26. High-Assurance Enforcement . . . . . . . . . . . . . . . . . 50
27. Deployment Patterns . . . . . . . . . . . . . . . . . . . . . 51
27.1. Finality Sink Performs Live Decision Query . . . . . . . 52
27.2. Portable Signed Decision Evidence . . . . . . . . . . . 52
27.3. Protected Decision Reference . . . . . . . . . . . . . . 52
27.4. Hybrid Evidence plus Current-State Check . . . . . . . . 52
28. Performance and Availability . . . . . . . . . . . . . . . . 52
29. Complementary Industrial Alignment . . . . . . . . . . . . . 52
30. Required Classes of Test Vectors . . . . . . . . . . . . . . 53
31. Questions to the IETF Community . . . . . . . . . . . . . . . 54
32. Potential IETF Discussion Venues and Scope Boundaries . . . . 55
32.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 56
32.2. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 56
32.3. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . 56
32.4. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 56
32.5. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 56
32.6. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 56
32.7. No Presumed Home . . . . . . . . . . . . . . . . . . . . 56
33. Relationship to Other Execution-Finality Internet-Drafts . . 56
34. Public Implementations and Companion Engineering Material . . 58
35. Security Considerations . . . . . . . . . . . . . . . . . . . 58
35.1. Compromised Intermediary . . . . . . . . . . . . . . . . 58
35.2. Compromised Requester or Agent . . . . . . . . . . . . . 58
35.3. Decision-Authority Compromise . . . . . . . . . . . . . 59
35.4. Evidence Forgery . . . . . . . . . . . . . . . . . . . . 59
35.5. Wrong-Authority Substitution . . . . . . . . . . . . . . 59
35.6. Exact-Act Substitution . . . . . . . . . . . . . . . . . 59
35.7. Evidence Replay and Bearerization . . . . . . . . . . . 59
35.8. Stale Decision Basis . . . . . . . . . . . . . . . . . . 59
35.9. Revocation After Evidence Issuance . . . . . . . . . . . 59
35.10. Required Evidence Omission . . . . . . . . . . . . . . . 59
35.11. Conflicting Authorities and Threshold Rules . . . . . . 60
35.12. Audience, Sink, Tenant, and Jurisdiction Confusion . . . 60
35.13. Canonicalization . . . . . . . . . . . . . . . . . . . . 60
35.14. TOCTOU Between Evidence Verification and Commit . . . . 60
Das Expires 20 March 2027 [Page 5]
Internet-Draft Third-Party Decision Binding September 2026
35.15. Evidence Cache Rollback . . . . . . . . . . . . . . . . 60
35.16. Lost or Reordered Decision Events . . . . . . . . . . . 60
35.17. Alternate Effectuation Path . . . . . . . . . . . . . . 61
35.18. Fail-Open Behavior . . . . . . . . . . . . . . . . . . . 61
35.19. Denial of Service . . . . . . . . . . . . . . . . . . . 61
35.20. Audit Receipt Confused with Execution Authority . . . . 61
35.21. SCITT Registration Is Not Semantic Correctness . . . . . 61
35.22. Verifier Compromise . . . . . . . . . . . . . . . . . . 61
35.23. Crash Consistency . . . . . . . . . . . . . . . . . . . 61
35.24. Evidence Retention . . . . . . . . . . . . . . . . . . . 62
35.25. Out-of-Scope Failures . . . . . . . . . . . . . . . . . 62
36. Privacy Considerations . . . . . . . . . . . . . . . . . . . 62
37. Criticism, Corrections, and Review Invited . . . . . . . . . 62
38. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
39. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 63
40. Normative References . . . . . . . . . . . . . . . . . . . . 63
41. Informative References . . . . . . . . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction
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.
Das Expires 20 March 2027 [Page 6]
Internet-Draft Third-Party Decision Binding September 2026
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 |
+-----------------------+
Figure 1: The unprovable third-party check
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
Das Expires 20 March 2027 [Page 7]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 8]
Internet-Draft Third-Party Decision Binding September 2026
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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals.
3. 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?
Das Expires 20 March 2027 [Page 9]
Internet-Draft Third-Party Decision Binding September 2026
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.
4. 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.
+-------------------------+
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
Figure 2: Verifiable external-decision binding
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.
Das Expires 20 March 2027 [Page 10]
Internet-Draft Third-Party Decision Binding September 2026
5. Problem Space
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. Threat Model and Assurance Scope
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.
Das Expires 20 March 2027 [Page 11]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 12]
Internet-Draft Third-Party Decision Binding September 2026
7. 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.
8. Existing Mechanisms and the Proposed Delta
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.
Das Expires 20 March 2027 [Page 13]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 14]
Internet-Draft Third-Party Decision Binding September 2026
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. Prevention, Mitigation, and Auditability
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.
Das Expires 20 March 2027 [Page 15]
Internet-Draft Third-Party Decision Binding September 2026
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.
10. 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.
Das Expires 20 March 2027 [Page 16]
Internet-Draft Third-Party Decision Binding September 2026
*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.
11. 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.
Das Expires 20 March 2027 [Page 17]
Internet-Draft Third-Party Decision Binding September 2026
12. 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)
Das Expires 20 March 2027 [Page 18]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 19]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 20]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 21]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 22]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 23]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 24]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 25]
Internet-Draft Third-Party Decision Binding September 2026
13. 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.
+-----------------+ 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.
Figure 3: Multiple required decision authorities
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.
Das Expires 20 March 2027 [Page 26]
Internet-Draft Third-Party Decision Binding September 2026
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
Figure 4: Authority-rule types beyond simple conjunction
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.
Figure 5: Decision-authority dependency graph
14. 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.
Das Expires 20 March 2027 [Page 27]
Internet-Draft Third-Party Decision Binding September 2026
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
Figure 6: Wrong-act substitution
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.
Application object
|
v
+----------------------+
| CanonicalSecurityAct |
| amount |
| resource |
| operation |
| destination |
| purpose |
| critical parameters |
+----------+-----------+
|
+---- H(C) ----> External Authority
|
+---- H(C) ----> Finality Sink
If authority hashes C1 and sink effects C2:
H(C1) != H(C2) => REJECT
Figure 7: Canonical act binding across authority and sink
Das Expires 20 March 2027 [Page 28]
Internet-Draft Third-Party Decision Binding September 2026
15. 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.
Finality Sink External/Policy State
| |
| verify E under G17 |
| |
| change -> G18 |
| |
| enter protected commit |
| assert generation == G17 --FAIL |
| |
+---- refresh / re-authorize ------+
Figure 8: Decision generation changes before protected commit
Das Expires 20 March 2027 [Page 29]
Internet-Draft Third-Party Decision Binding September 2026
Attacker obtains valid E_i
|
v
presents E_i
|
v
+---------------------------+
| Finality Sink |
| exact act? |
| sink/tenant? |
| transaction? |
| freshness? |
| consumed already? |
+-----------+---------------+
|
any mismatch
|
v
REJECT
Valid signature alone does not imply reusable authority.
Figure 9: Independently verifiable evidence need not be bearer
authority
16. 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.
17. State Machine
Das Expires 20 March 2027 [Page 30]
Internet-Draft Third-Party Decision Binding September 2026
+----------------+
| PROPOSED ACT C |
+-------+--------+
|
v
+-----------------------+
| DETERMINE REQUIRED |
| AUTHORITIES R(C) |
+----------+------------+
|
v
+-----------------------+
| OBTAIN / RESOLVE EDE |
| FOR EACH REQUIRED A_i |
+----------+------------+
|
v
+-----------------------+
| NON-EFFECTIVE |
| PENDING FINAL CHECK |
+----------+------------+
|
v
+-----------------------+
| FINALITY SINK |
| verify issuer |
| exact act |
| current basis |
| freshness/replay |
| sink/use |
| complete authority set|
+----+-------------+----+
| |
fail pass
| |
v v
NON-EFFECTIVE PROTECTED COMMIT
/ REAUTHORIZE |
v
EFFECTIVE
Figure 10: External-decision finality state machine
Das Expires 20 March 2027 [Page 31]
Internet-Draft Third-Party Decision Binding September 2026
+------------------+
| 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
Figure 11: Expanded decision-evidence state machine
Das Expires 20 March 2027 [Page 32]
Internet-Draft Third-Party Decision Binding September 2026
18. Solution Architecture
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
Das Expires 20 March 2027 [Page 33]
Internet-Draft Third-Party Decision Binding September 2026
+----------------------+
| 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
Das Expires 20 March 2027 [Page 34]
Internet-Draft Third-Party Decision Binding September 2026
Figure 12: End-to-end external-decision finality flow
19. 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.
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
Das Expires 20 March 2027 [Page 35]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 36]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 37]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 38]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 39]
Internet-Draft Third-Party Decision Binding September 2026
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)
}
Das Expires 20 March 2027 [Page 40]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 41]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 42]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 43]
Internet-Draft Third-Party Decision Binding September 2026
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
Das Expires 20 March 2027 [Page 44]
Internet-Draft Third-Party Decision Binding September 2026
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
20. 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.
Das Expires 20 March 2027 [Page 45]
Internet-Draft Third-Party Decision Binding September 2026
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.
Figure 13: Live query versus portable evidence
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
Figure 14: Live query must still bind the exact act
Das Expires 20 March 2027 [Page 46]
Internet-Draft Third-Party Decision Binding September 2026
21. 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 / 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
Figure 15: Audit-only evidence versus prevention
The two flows can coexist. The distinction is whether evidence
verification is a prerequisite to effectuation.
22. 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.
Das Expires 20 March 2027 [Page 47]
Internet-Draft Third-Party Decision Binding September 2026
23. 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.
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
Figure 16: Decision dependency across a multi-hop chain
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.
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.
Das Expires 20 March 2027 [Page 48]
Internet-Draft Third-Party Decision Binding September 2026
Figure 17: Decision context can become stale across asynchronous hops
24. 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.
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.
Figure 18: Required-decision verification bypass
25. Attack Analysis
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.
Das Expires 20 March 2027 [Page 49]
Internet-Draft Third-Party Decision Binding September 2026
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.
26. High-Assurance Enforcement
Das Expires 20 March 2027 [Page 50]
Internet-Draft Third-Party Decision Binding September 2026
Compromisable plane
+----------------------------------------------+
| Agent | App | OS | Orchestrator | Local PDP |
+------------------------+---------------------+
|
v
+-------------------------+
| PROTECTED FINALITY SINK |
| trusted authority roots |
| exact-act verification |
| current state |
| required decision set |
| atomic protected commit |
+------------+------------+
|
v
EFFECT K
Figure 19: Decision verification below a compromisable host
A high-assurance profile cannot rely on a compromised host to attest
that it performed the required decision checks. Verification state
and protected commit must be anchored below or outside that trust
boundary.
Compromisable plane
+--------------------------------------------------+
| Agent | App | OS | Orchestrator | Evidence Cache|
+--------------------------+-----------------------+
|
v
+----------------------------+
| PROTECTED FINALITY SINK |
| reconstruct exact C |
| resolve protected R(C) |
| verify E_i / live decisions|
| current generation |
| replay / use constraints |
| protected commit |
+-------------+--------------+
|
v
EFFECT K
Figure 20: Decision verification below a compromised host
27. Deployment Patterns
Das Expires 20 March 2027 [Page 51]
Internet-Draft Third-Party Decision Binding September 2026
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.
28. 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.
29. Complementary Industrial Alignment
Microsoft Entra Continuous Access Evaluation demonstrates event-
driven enforcement of critical identity and risk changes by relying
applications and resource providers [MS-CAE]. Amazon Verified
Permissions/Cedar provides externalized authorization decisions over
principal, action, resource, and context [AWS-AVP]. Google Cloud IAM
deny policies provide centrally managed prohibitions over principals
and permissions [GOOGLE-IAM].
Das Expires 20 March 2027 [Page 52]
Internet-Draft Third-Party Decision Binding September 2026
NVIDIA attestation and Arm CCA provide protected-compute and
attestation mechanisms that can supply trust inputs or host protected
verification/enforcement components [NVIDIA-ATTEST] [ARM-CCA].
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.
30. 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;
Das Expires 20 March 2027 [Page 53]
Internet-Draft Third-Party Decision Binding September 2026
* 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.
31. 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.
1. Does [MUNOZ-EVIDENCE] together with [MUNOZ-SCITT] already
provide the full proposed invariant when the actual effectuation
boundary verifies the Permit before effectuation?
2. If not, what exact residual property remains: authority
provenance, exact-act binding, currentness, sink binding,
required-decision-set semantics, or effectuation coupling?
3. Should this work therefore be a BCP or architecture/problem
statement rather than a new evidence format?
4. Is the term External Decision Evidence useful, or does existing
IETF terminology already cover the same architectural role?
5. When a Resource Server directly queries an authoritative third
party over an authenticated channel immediately before
effectuation, is portable evidence unnecessary?
6. When does a live authenticated query provide stronger semantics
than a portable signed decision object?
Das Expires 20 March 2027 [Page 54]
Internet-Draft Third-Party Decision Binding September 2026
7. Should portable Decision Evidence normally be audience/sink
bound, or is exact-act binding sufficient for common
deployments?
8. How should policy-generation or revocation changes invalidate
otherwise authentic Decision Evidence?
9. How should several required authorities be represented without
defining a universal policy language?
10. Are threshold or quorum decision rules appropriate in an IETF
security-architecture document?
11. How should an implementation distinguish Decision Evidence from
bearer execution authority?
12. What canonicalization rules are necessary to prevent evidence
from being rebound to a semantically different act?
13. Can SCITT receipts provide useful transparency and
accountability while remaining outside the hot path?
14. What is the correct relationship between SCITT registration
proof and execution-time authorization?
15. For RATS, when is an Attestation Result sufficient as a required
external decision, and when must it be rebound to a concrete
Candidate Act?
16. How should WIMSE identity and delegation context be associated
with evidence without duplicating WIMSE credential formats?
17. Which existing commercial or standards-based systems already
guarantee this invariant in full?
18. What counterexample would falsify or materially narrow the need
for this architecture?
19. Which deployment classes inherently provide only auditability or
mitigation rather than prevention?
20. Which venue is most appropriate for further discussion: OAuth,
WIMSE, SCITT, RATS, DISPATCH, SAAG, or another group?
32. Potential IETF Discussion Venues and Scope Boundaries
Das Expires 20 March 2027 [Page 55]
Internet-Draft Third-Party Decision Binding September 2026
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.
33. Relationship to Other Execution-Finality Internet-Drafts
This document isolates third-party decision binding rather than
repeating the broader execution-finality architecture.
Das Expires 20 March 2027 [Page 56]
Internet-Draft Third-Party Decision Binding September 2026
* 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 [DAS-PROTOCOL], [DAS-AGENTIC],
[DAS-HARDWARE], [DAS-RATS], [DAS-STATE], [DAS-REVOCATION],
[DAS-PATH], [DAS-PURPOSE], and [DAS-INTEROP].
Das Expires 20 March 2027 [Page 57]
Internet-Draft Third-Party Decision Binding September 2026
34. 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 [GH-ARCH] and [GH-HARDENED]. 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.
35. 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.
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.
Das Expires 20 March 2027 [Page 58]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 59]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 60]
Internet-Draft Third-Party Decision Binding September 2026
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.
Das Expires 20 March 2027 [Page 61]
Internet-Draft Third-Party Decision Binding September 2026
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.
36. 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.
37. 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.
Das Expires 20 March 2027 [Page 62]
Internet-Draft Third-Party Decision Binding September 2026
38. IANA Considerations
This document has no IANA actions.
39. 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.
40. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
41. Informative References
Das Expires 20 March 2027 [Page 63]
Internet-Draft Third-Party Decision Binding September 2026
[AIAGENT-AUTH]
Internet-Draft authors, "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
klrc-aiagent-auth-03, July 2026,
<https://datatracker.ietf.org/doc/draft-klrc-aiagent-
auth/>.
[ARM-CCA] Arm, "Arm Confidential Compute Architecture", 2026,
<https://www.arm.com/architecture/security-features/arm-
confidential-compute-architecture>.
[AWS-AVP] Amazon Web Services, "Amazon Verified Permissions
Documentation", 2026,
<https://docs.aws.amazon.com/verifiedpermissions/>.
[DAS-AGENTIC]
Das, S., "Execution-Finality for Agentic AI Tool
Dispatch", Work in Progress, Internet-Draft, draft-das-
agentic-execution-finality-00, August 2026,
<https://datatracker.ietf.org/doc/draft-das-agentic-
execution-finality/>.
[DAS-HARDWARE]
Das, S., "Hardware-Rooted National Control to Prevent
Covert Intelligence Data Export and Unauthorized Frontier
and Neural AI/Autonomous Acts in Critical Infrastructure",
Work in Progress, Internet-Draft, draft-das-hardware-
enforced-execution-finality-00, August 2026,
<https://datatracker.ietf.org/doc/draft-das-hardware-
enforced-execution-finality/>.
[DAS-INTEROP]
Das, S., "Breaking the Apple-Siri EU DMA Deadlock Without
Sacrificing Privacy or Security", Work in Progress,
Internet-Draft, draft-das-execution-finality-ai-
interoperability-00, August 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-ai-interoperability/>.
[DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path
Completeness for Execution Finality", Work in Progress,
Internet-Draft, draft-das-consequence-path-completeness-
00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
consequence-path-completeness-00>.
Das Expires 20 March 2027 [Page 64]
Internet-Draft Third-Party Decision Binding September 2026
[DAS-PROTOCOL]
Das, S., "The Missing Execution-Finality Protocol Layer of
the Internet", Work in Progress, Internet-Draft, draft-
das-execution-finality-protocol-layer-00, August 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-protocol-layer/>.
[DAS-PURPOSE]
Das, S., "Data-Purpose Laundering Prevention: Execution-
Finality for Preventing Cross-Domain Data Reuse", Work in
Progress, Internet-Draft, draft-das-purpose-execution-
finality-03, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-purpose-
execution-finality-03>.
[DAS-RATS] Das, S., "Attestation-Bound Execution Finality for GPU, AI
Accelerator, DPU, SmartNIC, and Confidential-Computing
Infrastructure", Work in Progress, Internet-Draft, draft-
das-rats-attestation-bnd-execution-finality-04, September
2026, <https://datatracker.ietf.org/doc/html/draft-das-
rats-attestation-bnd-execution-finality-04>.
[DAS-REVOCATION]
Das, S., "Revoked but Still Executable: Closing the
Authorization-to-Effect Gap with Finality-Bound
Revocation", Work in Progress, Internet-Draft, draft-das-
finality-bound-revocation-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-finality-
bound-revocation-00>.
[DAS-STATE]
Das, S., "When Valid Authorization Becomes Stale: State
and Policy Continuity at the Execution-Finality Boundary",
Work in Progress, Internet-Draft, draft-das-state-policy-
continuity-finality-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-state-
policy-continuity-finality-00>.
[GH-ARCH] Das, S., "Execution-Finality Architecture for Machine-
Generated Acts", 2026, <https://github.com/sangmdas/
Execution-Finality-Architechture-for-AI-Machines->.
[GH-HARDENED]
Das, S., "Hardened Challenge-Bound Execution Finality for
AI Interoperability", 2026, <https://github.com/sangmdas/
Hardened-Challenge-Bound-Execution-Finality-for-AI-
Interoperability>.
Das Expires 20 March 2027 [Page 65]
Internet-Draft Third-Party Decision Binding September 2026
[GOOGLE-IAM]
Google Cloud, "Deny access to resources — Identity and
Access Management", 2026,
<https://docs.cloud.google.com/iam/docs/deny-access>.
[MS-CAE] Microsoft, "Build resilience by using Continuous Access
Evaluation in Microsoft Entra ID", 2026,
<https://learn.microsoft.com/en-us/entra/architecture/
resilience-with-continuous-access-evaluation>.
[MUNOZ-EVIDENCE]
Munoz, C., "Signed Authorization-Evidence Records for
WIMSE-Authorized AI Agent Actions", Work in Progress,
Internet-Draft, draft-munoz-wimse-authorization-evidence-
01, July 2026, <https://datatracker.ietf.org/doc/draft-
munoz-wimse-authorization-evidence/>.
[MUNOZ-SCITT]
Munoz, C., "A SCITT Profile for Pre-Execution AI Action
Authorization Records", Work in Progress, Internet-Draft,
draft-munoz-scitt-permit-profile-01, July 2026,
<https://datatracker.ietf.org/doc/draft-munoz-scitt-
permit-profile/>.
[NVIDIA-ATTEST]
NVIDIA, "NVIDIA Attestation SDK — GPU and Switch
Attestation", 2026, <https://docs.nvidia.com/attestation/
attestation-client-tools-sdk/latest/
gpu_and_switch_attestation.html>.
[RFC7662] Richer, J., "OAuth 2.0 Token Introspection", RFC 7662,
October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.
[RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture",
RFC 9334, January 2023,
<https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9421] IETF, "HTTP Message Signatures", RFC 9421, February 2024,
<https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9943] IETF, "An Architecture for Trustworthy and Transparent
Digital Supply Chains", RFC 9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
Das Expires 20 March 2027 [Page 66]
Internet-Draft Third-Party Decision Binding September 2026
[TXN-TOKENS]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-11, July 2026,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-
transaction-tokens/>.
[WIMSE-ARCH]
IETF WIMSE Working Group, "Workload Identity in a Multi
System Environment (WIMSE) Architecture", Work in
Progress, Internet-Draft, draft-ietf-wimse-arch-08, July
2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
Author's Address
Sangam Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 20 March 2027 [Page 67]