When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary
draft-das-state-policy-continuity-finality-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-29 (Latest revision 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
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo 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-state-policy-continuity-finality-00
Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 16 September 2026
Expires: 20 March 2027
When Valid Authorization Becomes Stale: State and Policy Continuity at
the Execution-Finality Boundary
draft-das-state-policy-continuity-finality-00
Abstract
Security decisions are frequently made against mutable state. An
authorization decision may depend on a policy bundle, mapping table,
reference-value set, ownership record, revocation state, risk
classification, purpose grant, account state, or other data that can
change between evaluation and effectuation. A cryptographically
authentic permit can therefore remain valid as an object while
becoming stale as authority.
Existing freshness, replay-protection, sender-constraining,
attestation, and anti-rollback mechanisms solve important parts of
this problem. They do not by themselves establish that the exact
policy and state basis used to approve an act is still the applicable
basis when that act becomes externally effective.
This document describes a state- and policy-continuity model for
execution finality. A Candidate Act remains non-effective until a
protected Finality Sink verifies the concrete act, the identity of
the evaluated policy or mapping content, protected generations or
epochs, relevant mutable state, freshness, and authorized-use
constraints immediately before effectuation.
The model treats revision identity as content-bound rather than
merely name- or location-bound. A change from one mapping or policy
revision to another is a state transition that requires re-evaluation
unless an authoritative mechanism explicitly establishes
applicability across revisions. The Finality Sink is not expected to
infer semantic equivalence dynamically.
The model complements, rather than replaces, mechanisms such as RATS,
Entity Attestation Tokens, SUIT anti-rollback controls, OAuth fine-
grained authorization, sender-constrained tokens, and application
policy engines. Its central invariant is that authorization valid at
evaluation time is not automatically authority at effectuation time.
Das Expires 20 March 2027 [Page 1]
Internet-Draft State and Policy Continuity September 2026
The problem is industrially relevant to systems that already combine
continuously evaluated access, fine-grained policy decisions,
attestation, and confidential computing. Examples of complementary
industry directions include Microsoft Entra Continuous Access
Evaluation, Amazon Verified Permissions and Cedar, Google Cloud IAM
policy enforcement, NVIDIA GPU and switch attestation, and Arm
Confidential Compute Architecture. These names identify useful
integration and comparison points; they are not assertions of
vulnerability, deficiency, non-conformance, or endorsement by any
named organization.
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.
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.
Das Expires 20 March 2027 [Page 2]
Internet-Draft State and Policy Continuity September 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Requirements Language . . . . . . . . . . . . 6
3. Motivating Scenario: Policy Revision Between Approval and
Effectuation . . . . . . . . . . . . . . . . . . . . . . 6
4. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Freshness Is Not State Continuity . . . . . . . . . . . . 7
4.2. Signature Validity Is Not Current Applicability . . . . . 8
4.3. A Policy Name or Location Is Not a Revision Identity . . 8
5. Threat Model and Assurance Scope . . . . . . . . . . . . . . 8
5.1. Direct Question: What Threat Does This Architecture
Solve? . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Adversary Capabilities . . . . . . . . . . . . . . . . . 9
5.3. Baseline Continuity Profile . . . . . . . . . . . . . . . 10
5.4. High-Assurance Continuity Profile . . . . . . . . . . . . 10
5.5. Trust Assumptions and Out-of-Scope Compromise . . . . . . 11
5.6. Availability and Denial of Service . . . . . . . . . . . 11
6. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 11
7. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Continuity Binding Model . . . . . . . . . . . . . . . . . . 13
9. Formal Mathematical Model . . . . . . . . . . . . . . . . . . 14
9.1. Authorization at Evaluation Time . . . . . . . . . . . . 14
9.2. Decision-Basis Identity . . . . . . . . . . . . . . . . . 15
9.3. Candidate-Scoped Compatibility . . . . . . . . . . . . . 15
9.4. Continuity Predicate . . . . . . . . . . . . . . . . . . 15
9.5. Safety Invariant . . . . . . . . . . . . . . . . . . . . 16
9.6. Bounded Prevention Argument . . . . . . . . . . . . . . . 16
9.7. Continuity Decision Diagram . . . . . . . . . . . . . . . 16
10. Finality Predicate and Safety Invariant . . . . . . . . . . . 17
11. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Decision-Basis Continuity Diagrams . . . . . . . . . . . . . 19
13. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Prepare . . . . . . . . . . . . . . . . . . . . . . . . 20
13.2. Evaluate . . . . . . . . . . . . . . . . . . . . . . . . 21
13.3. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.4. Finalize . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 21
14.1. Build the Load-Bearing Decision Basis . . . . . . . . . 21
14.2. Evaluate and Bind Candidate Act . . . . . . . . . . . . 21
14.3. Validate Candidate-Scoped Compatibility Evidence . . . . 22
14.4. Check Continuity Against Current Basis . . . . . . . . . 22
14.5. Finalize with Protected Generation Check . . . . . . . . 23
14.6. Invalidate or Revalidate After Basis Change . . . . . . 25
14.7. Handle a Concurrent Policy Update . . . . . . . . . . . 25
14.8. Crash and Recovery Handling . . . . . . . . . . . . . . 25
14.9. Continuity-Finalization Flow Diagram . . . . . . . . . . 26
15. End-to-End Architecture . . . . . . . . . . . . . . . . . . . 26
Das Expires 20 March 2027 [Page 3]
Internet-Draft State and Policy Continuity September 2026
16. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Policy Rollback . . . . . . . . . . . . . . . . . . . . 28
16.2. Mapping Revision Substitution . . . . . . . . . . . . . 28
16.3. Reference-State Rollback . . . . . . . . . . . . . . . . 28
16.4. Stale Permit Replay . . . . . . . . . . . . . . . . . . 28
16.5. Split-Brain Authority State . . . . . . . . . . . . . . 28
16.6. Semantic-Equivalence Confusion . . . . . . . . . . . . . 29
16.7. Crash and Snapshot Rollback . . . . . . . . . . . . . . 29
17. Bounded and Non-Bearer-Like Authorization . . . . . . . . . . 29
18. The Alternate-Path Requirement . . . . . . . . . . . . . . . 29
19. Concurrency, Generations, and Policy Heads . . . . . . . . . 30
20. Applicability Beyond a Single Policy Engine . . . . . . . . . 30
21. Industrial Relevance and Complementary Standards Alignment . 31
21.1. Agentic and Automated Tool Execution . . . . . . . . . . 31
21.2. Microsoft Entra Continuous Access Evaluation . . . . . . 31
21.3. Amazon Verified Permissions and Cedar . . . . . . . . . 32
21.4. Google Cloud IAM Policy Enforcement . . . . . . . . . . 32
21.5. OAuth and Resource-Server Enforcement . . . . . . . . . 32
21.6. RATS and Attestation-Based Decisions . . . . . . . . . . 32
21.7. NVIDIA Attestation and Arm Confidential Compute
Architecture . . . . . . . . . . . . . . . . . . . . . . 33
21.8. SUIT and Anti-Rollback Patterns . . . . . . . . . . . . 33
21.9. Confidential and High-Assurance Computing . . . . . . . 33
22. Open Questions, Critique, and Corrections Invited . . . . . . 33
23. Questions to the IETF Community . . . . . . . . . . . . . . . 35
24. Relationship to Existing Work . . . . . . . . . . . . . . . . 36
24.1. RATS and EAT . . . . . . . . . . . . . . . . . . . . . . 36
24.2. SUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 36
24.3. TEEP . . . . . . . . . . . . . . . . . . . . . . . . . . 37
24.4. OAuth Fine-Grained and Sender-Constrained
Authorization . . . . . . . . . . . . . . . . . . . . . 37
24.5. Related Execution-Finality Internet-Drafts . . . . . . . 37
24.6. Public Implementations and Companion Engineering
Material . . . . . . . . . . . . . . . . . . . . . . . . 37
24.7. IETF Security-Area Relevance . . . . . . . . . . . . . . 38
24.8. Potential IETF Discussion Venues and Scope Boundaries . 38
25. Operational and Deployment Considerations . . . . . . . . . . 40
25.1. Choosing the Decision-Basis Scope . . . . . . . . . . . 40
25.2. Digest Granularity . . . . . . . . . . . . . . . . . . . 40
25.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . 40
25.4. Distributed State and Temporary Inconsistency . . . . . 40
25.5. Failure Handling . . . . . . . . . . . . . . . . . . . . 41
26. Security Considerations . . . . . . . . . . . . . . . . . . . 41
26.1. Compromised Requester . . . . . . . . . . . . . . . . . 41
26.2. Compromised Policy or Mapping Service . . . . . . . . . 41
26.3. Time-of-Check to Time-of-Use . . . . . . . . . . . . . . 41
26.4. Rollback Protection . . . . . . . . . . . . . . . . . . 41
26.5. Canonicalization and Content Identity . . . . . . . . . 42
Das Expires 20 March 2027 [Page 4]
Internet-Draft State and Policy Continuity September 2026
26.6. Semantic Equivalence . . . . . . . . . . . . . . . . . . 42
26.7. Revocation Race . . . . . . . . . . . . . . . . . . . . 42
26.8. Split-Brain and Partitioned Authorities . . . . . . . . 42
26.9. Non-Bypassability . . . . . . . . . . . . . . . . . . . 42
26.10. Crash Consistency . . . . . . . . . . . . . . . . . . . 43
26.11. Fail-Closed Behavior and Denial of Service . . . . . . . 43
27. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
28. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
29. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 43
30. Normative References . . . . . . . . . . . . . . . . . . . . 44
31. Informative References . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
Many security protocols answer a question at a particular point in
time. A verifier appraises evidence, an authorization server issues
a token, a policy engine returns "allow", an administrator approves a
deployment, or an orchestration system validates a concrete
operation. The resulting decision can be entirely correct when it is
made.
The protected consequence, however, can occur later. Between
evaluation and effectuation, a policy can be revised, an account can
be suspended, a mapping can change, a resource can advance to a new
generation, a reference-value set can be replaced, a purpose grant
can be narrowed, or an emergency revocation can become active.
evaluate under state S17 effect under state S18
Candidate Act
|
v
Policy P17 / Map M17
|
v
ALLOW + Permit
|
| policy, mapping, revocation,
| ownership, or reference state changes
v
-------------------- time -------------------->
|
v
External Effect
Figure 1: The state-continuity gap
Das Expires 20 March 2027 [Page 5]
Internet-Draft State and Policy Continuity September 2026
The permit can still possess a valid signature. Its nonce can still
be fresh enough for its protocol. Its presenter can still prove
possession of the expected key. Those facts do not necessarily
establish that the decision basis used to authorize the act remains
current.
This document calls the required property *state and policy
continuity*: security-relevant state used to authorize an act must
remain bound to that act through the point at which the protected
consequence first becomes effective, or it must be re-established
there under an equivalently strong rule.
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, as shown here.
3. Motivating Scenario: Policy Revision Between Approval and
Effectuation
Consider an agentic or automated system preparing a high-consequence
operation. Policy revision P17 permits operation O for principal A
when destination D, amount L, purpose U, and device posture Q satisfy
specified conditions. A policy engine evaluates the concrete
Candidate Act under P17 and issues a permit bound to the act.
Before the operation becomes externally effective, policy revision
P18 is made active. P18 can revoke destination D, reduce limit L,
withdraw purpose U, change the required device posture, or revoke A
entirely. The reasons for the update are not material to this
document. What matters is that the security basis changed.
Das Expires 20 March 2027 [Page 6]
Internet-Draft State and Policy Continuity September 2026
t0 t1 t2
| | |
| evaluate C under P17 | activate P18 | effect C
|------------------------|------------------------|
| | |
v v v
+------+ +-----------+ +-------------+
| P17 | -- ALLOW --> | Permit A | | Finality |
+------+ | sig valid | | Sink |
+-----------+ +------+------+
|
if only signature | unsafe
and expiry checked v
External Effect
Figure 2: Cryptographically valid but state-stale authorization
A simple expiry window does not fully solve the problem. P18 can
become active one millisecond after P17 was evaluated. A short-lived
permit can therefore be fresh in time and stale in meaning.
The same structure appears outside agentic systems. A Relying Party
can act on attestation results after reference state changes; a
workload can execute under a stale authorization graph; a gateway can
use an earlier route-to-policy mapping; a device can restore an older
policy snapshot; or a resource operation can use an authorization
bound to a previous ownership epoch.
4. Problem Space
State continuity is distinct from message authenticity. A signed
policy object can be authentic and old. It is distinct from request
freshness. A fresh request can be evaluated against stale state. It
is distinct from proof of possession. A legitimate presenter can
present authority that no longer applies. It is also distinct from
attestation freshness: fresh evidence about a component does not, by
itself, identify which application policy revision governs the
effect.
4.1. Freshness Is Not State Continuity
RATS discusses freshness for Evidence, and EAT requires a freshness
mechanism to prevent replay and related attacks [RFC9334] [RFC9711].
This is essential. The continuity problem is different: even freshly
produced evidence can be appraised using reference data or policy
state that later changes before effectuation.
Das Expires 20 March 2027 [Page 7]
Internet-Draft State and Policy Continuity September 2026
A deployment therefore MUST distinguish at least two questions:
whether an input is fresh, and whether the security-relevant decision
basis remains applicable at the effectuation boundary.
4.2. Signature Validity Is Not Current Applicability
Cryptographic authenticity establishes who protected an object and
whether the protected bytes were modified. It does not inherently
establish that the object is the currently applicable revision.
Anti-rollback systems commonly add a monotonic sequence, generation,
or equivalent continuity mechanism for this reason.
RFC 9124 provides a concrete example in the firmware-update domain:
manifests carry monotonically increasing sequence numbers so devices
can reject older manifests under the relevant authority's policy
[RFC9124]. This document generalizes the continuity question to
authorization and effectuation state; it does not modify SUIT
requirements.
4.3. A Policy Name or Location Is Not a Revision Identity
A URI, database key, policy name, repository path, or logical mapping
identifier can continue to refer to an object whose content has
changed. Binding a permit only to such a locator therefore does not
necessarily bind the permit to what was evaluated.
Where policy or mapping content is security relevant, the evaluated
content SHOULD be identified by a collision-resistant digest,
authenticated immutable version, protected generation, or equivalent
content-specific identity.
Two revisions can be intended to be semantically equivalent even
though their bytes differ. A Finality Sink SHOULD NOT be required to
discover that equivalence dynamically. If cross-revision
applicability is permitted, it SHOULD be established by an
authoritative, machine-verifiable compatibility statement or by
explicit re-evaluation.
5. Threat Model and Assurance Scope
5.1. Direct Question: What Threat Does This Architecture Solve?
The direct threat is not merely theft or forgery of an authorization
object. The architecture addresses the case in which an
authorization can remain authentic, correctly signed, unexpired, and
legitimately possessed while the security-relevant state that made it
valid has changed before the protected consequence occurs.
Das Expires 20 March 2027 [Page 8]
Internet-Draft State and Policy Continuity September 2026
In the canonical case, Candidate Act C is correctly authorized under
Decision Basis B17. Before effectuation, B18 becomes authoritative
because policy, revocation, ownership, mapping, reference state, risk
state, purpose scope, resource generation, or another load-bearing
input changes. An attacker or ordinary requester then presents the
still-authentic authorization derived from B17. The architecture
solves this class by requiring the Finality Sink to establish that
the evaluated basis remains current or explicitly applicable to the
effect about to occur; otherwise the act is re-evaluated or remains
non-effective.
t0 t1 t2
| | |
| authorize C under B17 | B18 becomes current | effect C?
|--------------------------|--------------------------|
| | |
| valid authorization | old object still valid |
| | cryptographically |
| | |
+--------------------------+--------------------------+
|
v
Finality Sink checks
B17 -> current/applicable?
| |
no yes
| |
v v
reject or protected
re-evaluate commit
The security objective is therefore continuity of authorization
meaning through effectuation, not merely authenticity of the
authorization artifact. The model also covers rollback, stale-permit
replay, revision substitution, split-brain selection, crash or
snapshot restoration, revocation races, and alternate-path
effectuation when those mechanisms can cause an act to take effect
under state different from the state that was actually evaluated.
5.2. Adversary Capabilities
The adversary MAY control or compromise the requester, agent,
application process, orchestration layer, ordinary host software,
caches, untrusted persistent storage, and communication paths outside
the protected enforcement boundary. The adversary MAY capture and
replay previously valid authorization objects, present authentic but
stale policy or mapping objects, restore snapshots, substitute
mutable references, race policy changes against effectuation, exploit
Das Expires 20 March 2027 [Page 9]
Internet-Draft State and Policy Continuity September 2026
crash recovery, induce or exploit network partitions, and attempt to
reach the protected consequence through an alternate effectuation
path.
The adversary MAY possess legitimate credentials and MAY have been
legitimately authorized under an earlier Decision Basis. The
security property therefore does not depend on proving malicious
intent or on detecting credential theft. A principal that was
correctly authorized at time t1 can be unauthorized at time t2, while
still holding an authentic artifact issued at t1.
The requester is not authoritative for current policy, mapping,
revocation, ownership, or generation state. Security-critical
current-state information MUST be obtained from protected state or
from an authority whose authenticity and applicability satisfy the
deployment's threat model.
5.3. Baseline Continuity Profile
In the baseline profile, the requester, network path, untrusted
storage, cached authorizations, application software, and previously
issued authorization objects are considered potentially hostile or
stale. The authoritative current-state source and the Finality Sink
remain within the trusted computing base. The Finality Sink MUST NOT
accept requester-supplied claims of current policy or generation
without independently protected evidence.
This profile is suitable where the principal risk is reuse or
substitution of authorization after a legitimate decision, while the
policy authority and enforcement boundary themselves remain
trustworthy.
5.4. High-Assurance Continuity Profile
Higher-assurance deployments MAY additionally assume compromise of
the agent runtime, host application, orchestration software, general-
purpose operating system, hypervisor, policy-distribution cache, or
snapshot and recovery environment. Under such a threat model, those
components MUST NOT be able to reset the authoritative continuity
generation, fabricate current-state evidence, restore consumed
authority, or directly create the protected consequence outside the
Finality Sink.
Current-generation state, continuity evidence, authorization
consumption, and the final protected commit can be anchored in a
protection domain not writable by the compromised components, such as
an appropriately isolated TEE, security processor, HSM, DPU,
SmartNIC, protected firmware component, or equivalent protected
Das Expires 20 March 2027 [Page 10]
Internet-Draft State and Policy Continuity September 2026
enforcement boundary. This document does not require one particular
hardware technology; the requirement is protection of the load-
bearing state and effectuation path against the adversary defined by
the deployment.
5.5. Trust Assumptions and Out-of-Scope Compromise
The model assumes that the cryptographic primitives protecting
digests, signatures, MACs, authenticated state, and continuity
evidence remain secure and that at least one configured root of
authority or protected enforcement root required by the deployment
remains uncompromised. Compromise of every ultimate policy
authority, every configured trust anchor, or the Finality Sink itself
is outside the base threat model.
Deployments requiring tolerance of authority compromise MAY use
independent authorities, threshold authorization, replicated
protected state, transparency mechanisms, independent appraisal, or
separation of duties. Those mechanisms strengthen the trust model
but do not change the continuity invariant defined here.
This architecture does not claim to determine whether a policy is
substantively correct, infer human intent, eliminate implementation
bugs, eliminate all side channels, resist physical destruction of
trusted hardware, or protect a consequence reachable through a path
outside the defined enforcement boundary. Such mechanisms can be
complementary controls.
5.6. Availability and Denial of Service
An adversary can attempt to make current state unavailable by
attacking the policy-head service, continuity-evidence path, quorum,
or protected state source. This can deny or delay protected
operations. The architecture does not convert inability to establish
current applicability into authorization: for operations whose threat
model requires current continuity, unknown state MUST remain non-
authorizing unless an explicit bounded- staleness or emergency rule
has itself been authorized by policy.
6. Design Goals and Non-Goals
The design goal is to prevent an act authorized against one security-
relevant state from silently becoming effective under materially
different state. The protected binding covers the concrete act and
the decision basis required by the deployment, and the binding is
checked at the boundary where the protected consequence first becomes
effective.
Das Expires 20 March 2027 [Page 11]
Internet-Draft State and Policy Continuity September 2026
This document does not define a universal policy language, universal
policy equivalence algorithm, new attestation format, new OAuth grant
type, distributed consensus protocol, blockchain, or mandatory
transparency service. Those systems can provide inputs to the model.
The model also does not require that every policy update invalidate
every pending act. A deployment can define explicit compatibility or
transition rules. The requirement is that such applicability be
established by authority and evidence, not guessed by the executing
component after the decision basis changes.
7. Terminology
*Candidate Act:* A proposed operation capable of producing an
external, persistent, financial, administrative, physical,
disclosure, or other protected consequence, but which has not yet
been permitted to produce that consequence.
*Non-Effective State:* A condition in which a Candidate Act can be
computed, queued, validated, and authorized, while the requester
still lacks the means to create the protected consequence without
final enforcement.
*Decision Basis:* The security-relevant state against which the
Candidate Act was evaluated. It can include policy content,
mappings, reference values, ownership, revocation state, account
state, purpose grants, resource generations, risk data, or other
mutable inputs.
*Decision-Basis Digest:* A cryptographic commitment to the canonical
representation of the Decision Basis, or to a protected root that
unambiguously identifies the relevant state.
*Policy Generation:* A monotonically advancing epoch, sequence,
generation, or equivalent protected continuity value associated with
an authoritative policy state.
*Continuity Evidence:* Protected evidence establishing the relation
between the state used at evaluation and the state applicable at
effectuation.
*Execution Handle:* Narrowly scoped authorization bound to a
Candidate Act, its Decision Basis, and execution constraints.
Possession of the handle is not intended to create unconstrained
bearer authority for a different act or materially different state.
Das Expires 20 March 2027 [Page 12]
Internet-Draft State and Policy Continuity September 2026
*Finality Sink:* The protected functional boundary controlling the
first operation that makes the Candidate Act externally effective.
It can verify, reconstruct, or re-establish security-relevant state
immediately before allowing effectuation. The term denotes a role,
not a required physical location.
*Rollback:* Presentation, restoration, or use of an older security
state as though it were the currently applicable state, contrary to
the relevant authority's continuity policy.
*Revision Substitution:* Replacement of the evaluated policy,
mapping, or state object with a different revision after evaluation
but before effectuation.
8. Continuity Binding Model
Let Candidate Act C contain the concrete security-relevant act
parameters. Let B represent the security-relevant Decision Basis
used to evaluate C.
C = (subject, operation, object, destination, parameters, nonce, constraints)
B = (policy_digest,
mapping_digest,
reference_state_digest,
revocation_generation,
resource_generation,
authority_set_digest,
policy_generation)
A deployment need not use every field above. It MUST include or re-
establish every mutable field whose change can alter whether the
Candidate Act is permitted.
A canonical authorization binding can be represented as:
D_C = H(Encode(C))
D_B = H(Encode(B))
EH = Protect(D_C, D_B, UseConstraints, Freshness, IssuerContext)
The semantic requirement is not tied to a particular token format.
It is:
Authorization(C, B17) does not imply Authorization(C, B18)
when B17 and B18 differ in a security-relevant way.
Das Expires 20 March 2027 [Page 13]
Internet-Draft State and Policy Continuity September 2026
If B18 is explicitly declared compatible for C by an authority
recognized by the deployment, continuity can be established through
that declaration. Otherwise the act requires re-evaluation against
B18.
9. Formal Mathematical Model
This section makes the continuity requirement explicit independently
of any token format, policy language, or storage mechanism. The
model distinguishes the Candidate Act from the mutable Decision Basis
under which that act was evaluated.
Let:
C = concrete Candidate Act
B_t = authoritative Decision Basis at time t
D_C = H(Canonical(C))
D_B(t) = H(Canonical(B_t))
EH = execution authority / Execution Handle
CE = Continuity Evidence
G_t = protected current generation at time t
S_now = protected current state at the Finality Sink
Representative basis:
B_t = (
policy_digest,
mapping_digest,
reference_state_digest,
revocation_generation,
resource_generation,
authority_set_digest,
policy_generation)
Only load-bearing mutable fields need to be represented.
9.1. Authorization at Evaluation Time
An authorization decision is always relative to a particular Decision
Basis, even when an implementation does not expose that basis
explicitly.
AuthorizedAtEvaluation(C, B_e) :=
PolicyAllows(C, B_e)
AND ActWellFormed(C)
AND EvaluationInputsTrusted(B_e)
Issue(EH) only if AuthorizedAtEvaluation(C, B_e) = TRUE.
Das Expires 20 March 2027 [Page 14]
Internet-Draft State and Policy Continuity September 2026
9.2. Decision-Basis Identity
Names, URLs, object identifiers, or mutable storage locations are
insufficient as the sole identity of a load-bearing basis when their
contents can change. The continuity model uses content identity or
another protected immutable revision identity.
BasisIdentity(B) := H(Canonical(B))
ExactBasisMatch(B_e, B_now) :=
BasisIdentity(B_e) = BasisIdentity(B_now)
9.3. Candidate-Scoped Compatibility
Exact content identity is the safe default, but a deployment can
permit a basis revision without full re-evaluation when an authority
recognized by policy issues a machine-verifiable compatibility
statement scoped to the Candidate Act or act class.
CompatibleFor(C, B_e, B_now, CE) :=
VerifyCompatibilityAuthority(CE)
AND CE.old_basis_digest = BasisIdentity(B_e)
AND CE.new_basis_digest = BasisIdentity(B_now)
AND CE.scope_covers(C)
AND CE.generation = CurrentProtectedGeneration()
AND CE.not_expired
ContinuityOfBasis(C, B_e, B_now, CE) :=
ExactBasisMatch(B_e, B_now)
OR CompatibleFor(C, B_e, B_now, CE)
9.4. Continuity Predicate
The continuity predicate joins exact-act binding, basis continuity,
mutable-state currentness, authorized-use constraints, and path
authorization at the Finality Sink.
ContinuityValid(C, EH, B_now, CE, S_now) :=
EH.act_digest = H(Canonical(C))
AND ContinuityOfBasis(C, EH.evaluated_basis, B_now, CE)
AND PolicyGenerationCurrent(B_now, S_now)
AND MappingRevisionApplicable(C, B_now)
AND RevocationStateCurrent(C, B_now, S_now)
AND ResourceGenerationCurrent(C, B_now, S_now)
AND AuthoritySetCurrent(C, B_now, S_now)
AND FreshnessValid(EH, S_now)
AND AuthorizedUseValid(EH, C, S_now)
AND EffectuationPathAuthorized(C, S_now)
Das Expires 20 March 2027 [Page 15]
Internet-Draft State and Policy Continuity September 2026
9.5. Safety Invariant
Effective(C)
=>
ContinuityValid(C, EH, B_now, CE, S_now) = TRUE
Strict prevention form:
NOT ContinuityValid(C, EH, B_now, CE, S_now)
=>
NOT Effective(C)
9.6. Bounded Prevention Argument
Assume that the Finality Sink controls every modeled path capable of
making C effective; the exact pending act is observable there;
current Decision Basis and generation state are protected against
rollback; compatibility evidence cannot be forged for an untrusted
authority; and the continuity check is coupled atomically or
equivalently to the protected commit. Under those assumptions, a
Candidate Act evaluated under stale basis B_e cannot become effective
under materially different B_now unless exact continuity, an explicit
authorized compatibility relation, or a fresh re-evaluation
establishes applicability.
Proof sketch: if B_now differs materially and neither ExactBasisMatch
nor CompatibleFor is true, ContinuityOfBasis is false. Therefore
ContinuityValid is false, and by the strict prevention rule
Effective(C) must remain false. A successful stale-authority effect
must therefore break an explicit assumption: basis integrity,
current-generation integrity, compatibility authenticity, path
completeness, or commit ordering.
9.7. Continuity Decision Diagram
Das Expires 20 March 2027 [Page 16]
Internet-Draft State and Policy Continuity September 2026
Evaluation Effectuation
| |
| C allowed under B17 | current basis = B18
| EH binds H(C), H(B17) |
+----------------------+-------------+
|
v
+-------------------+
| B17 == B18 ? |
+----+---------+----+
| |
yes no
| |
v v
continue compatible for C ?
/ \
yes no
| |
v v
continue re-evaluate
or reject
Figure 3: B17 to B18 continuity decision
10. Finality Predicate and Safety Invariant
Immediately before effectuation, the Finality Sink evaluates a
predicate Phi over the concrete Candidate Act, current protected
state, the Execution Handle, and continuity evidence.
Phi(C, S_now, EH, CE) =
ExactActBinding
AND DecisionBasisBindingValid
AND CurrentGenerationAcceptable
AND MappingRevisionApplicable
AND RevocationStateCurrent
AND ResourceGenerationCurrent
AND FreshnessValid
AND AuthorizationUseValid
AND ContinuityEvidenceValid
AND EffectuationPathAuthorized
The fundamental safety invariant is:
Effective(C) => Phi(C, S_now, EH, CE) = TRUE
Das Expires 20 March 2027 [Page 17]
Internet-Draft State and Policy Continuity September 2026
It is insufficient that Phi would have been true at an earlier time.
If state material to authorization can change, the Finality Sink MUST
establish that the evaluated basis remains applicable, or MUST
trigger re-evaluation before allowing the act to become effective.
11. State Machine
A deployment can collapse internal implementation states, but it MUST
preserve the property that policy or state drift cannot silently turn
previously valid approval into current execution authority.
+-----------+
| PROPOSED |
+-----+-----+
|
| evaluate under basis B
v
+-----------+
| EVALUATED |
+-----+-----+
|
| bind C + B
v
+------------------+
| NON-EFFECTIVE |
| AUTHORIZED |
+--------+---------+
|
| final continuity check
v
+------------------+
| BASIS CURRENT OR |
| EXPLICITLY |
| APPLICABLE? |
+----+--------+----+
| |
no yes
| |
v v
RE-EVALUATE PROTECTED COMMIT
OR REJECT |
v
+---------+
| EFFECT |
+---------+
Figure 4: Illustrative state-continuity machine
Das Expires 20 March 2027 [Page 18]
Internet-Draft State and Policy Continuity September 2026
12. Decision-Basis Continuity Diagrams
The following diagrams separate three different failure surfaces:
stale-basis reuse, semantic-revision ambiguity, and a race between
the final continuity read and protected commit.
t0 t1 t2
| | |
| evaluate C under B17 | B18 becomes authoritative| Finality Sink
| issue EH bound to B17 | | receives C + EH
|--------------------------|--------------------------|
|
v
If B17 is no longer applicable:
old EH is NOT current authority.
Figure 5: Stale basis survives from evaluation to effectuation
SAFE DEFAULT
Mapping M17 content ------> digest D17
Mapping M18 content ------> digest D18
D17 == D18 ?
|
yes ---> exact continuity
|
no
v
explicit machine-verifiable compatibility proof?
| |
yes no
| |
v v
candidate-scoped RE-EVALUATE
compatibility (do not guess equivalence)
The Finality Sink compares protected identities;
it does not perform an open-ended semantic judgement.
Figure 6: Exact revision identity versus open-ended semantic guessing
Das Expires 20 March 2027 [Page 19]
Internet-Draft State and Policy Continuity September 2026
Finality thread Policy thread
--------------- -------------
read generation G17
verify C against B17
publish B18
advance generation G18
attempt protected commit
|
v
compare expected G17 with current G18
|
+---- mismatch ----> abort / re-evaluate
Only a commit that proves the observed generation
is still current may make the act effective.
Figure 7: Generation race at protected commit
B17 evaluation
|
| issue EH bound to C + B17
v
NON-EFFECTIVE C
|
B18 becomes current
|
+--> exact identity? ------------------ yes --> final check
|
+--> authoritative compatibility CE? -- yes --> final check
|
+--> otherwise ------------------------------> re-evaluate
CE proves only the permitted continuity relation.
Possession of CE alone does not make C effective.
Figure 8: Continuity evidence as an explicit bridge, not bearer
authority
13. Solution Overview
13.1. Prepare
The system constructs a Candidate Act and a canonical representation
of the security-relevant act parameters. Preparation MUST NOT itself
create the protected consequence.
Das Expires 20 March 2027 [Page 20]
Internet-Draft State and Policy Continuity September 2026
13.2. Evaluate
The policy or validation function evaluates the Candidate Act against
the Decision Basis. The Decision Basis SHOULD be represented by
content-specific identities and protected continuity values rather
than mutable names alone.
13.3. Bind
The system issues an Execution Handle or equivalent authorization
bound to the exact Candidate Act and to the Decision Basis used to
approve it. A security-relevant basis field MUST either be bound
into the authorization or be re-established at finalization under an
equivalent protected invariant.
13.4. Finalize
At the Finality Sink, the system reconstructs or observes the
concrete act, determines the current protected generation and state,
verifies continuity from the evaluated basis to the current basis,
and enforces authorized-use semantics. If continuity cannot be
established, the Candidate Act remains non-effective.
14. Illustrative Pseudocode
The following pseudocode is non-normative. It separates evaluation,
protected basis identity, compatibility evidence, concurrent
generation handling, finalization, invalidation, and crash recovery
so that the continuity invariant is implementation-visible rather
than implied.
14.1. Build the Load-Bearing Decision Basis
function build_decision_basis(candidate):
return DecisionBasis(
policy_digest = digest(current_policy_for(candidate)),
mapping_digest = digest(current_mapping_for(candidate)),
reference_state_digest = digest(current_reference_state(candidate)),
revocation_generation = current_revocation_generation(candidate),
resource_generation = current_resource_generation(candidate),
authority_set_digest = digest(current_authority_set(candidate)),
policy_generation = protected_policy_generation())
14.2. Evaluate and Bind Candidate Act
Das Expires 20 March 2027 [Page 21]
Internet-Draft State and Policy Continuity September 2026
function evaluate_and_bind(candidate):
C = canonical(candidate)
B = build_decision_basis(candidate)
if !policy_allows(C, B):
return DENY
return issue_execution_handle(
act_digest = H(C),
basis_digest = H(canonical(B)),
evaluated_basis = protected_reference(B),
policy_generation = B.policy_generation,
resource_generation = B.resource_generation,
revocation_generation = B.revocation_generation,
authority_set_digest = B.authority_set_digest,
nonce = secure_random(),
use_constraints = derive_use_constraints(C, B),
expiry = bounded_expiry())
14.3. Validate Candidate-Scoped Compatibility Evidence
function validate_compatibility(candidate, handle, B_now, CE):
if CE == NONE:
return FALSE
if !verify_signature_and_authority(CE):
return FALSE
if CE.old_basis_digest != handle.basis_digest:
return FALSE
if CE.new_basis_digest != H(canonical(B_now)):
return FALSE
if !CE.scope_covers(candidate):
return FALSE
if CE.generation != current_protected_generation():
return FALSE
if CE.expired:
return FALSE
return TRUE
14.4. Check Continuity Against Current Basis
Das Expires 20 March 2027 [Page 22]
Internet-Draft State and Policy Continuity September 2026
function continuity_check(candidate, handle, CE):
B_now = protected_current_basis(candidate)
if H(canonical(B_now)) == handle.basis_digest:
return CONTINUITY_EXACT
if validate_compatibility(candidate, handle, B_now, CE):
return CONTINUITY_EXPLICITLY_COMPATIBLE
return REEVALUATION_REQUIRED
14.5. Finalize with Protected Generation Check
Das Expires 20 March 2027 [Page 23]
Internet-Draft State and Policy Continuity September 2026
function finalize(observed_candidate, handle, CE):
begin_protected_finality_section()
C = canonical(observed_candidate)
if handle.expired or handle.consumed:
reject("expired or consumed authority")
if H(C) != handle.act_digest:
reject("exact-act mismatch")
observed_generation = current_protected_generation()
B_now = protected_current_basis(observed_candidate)
continuity = continuity_check(observed_candidate, handle, CE)
if continuity == REEVALUATION_REQUIRED:
return reevaluate_or_reject(observed_candidate, B_now)
if current_revocation_generation(observed_candidate) !=
B_now.revocation_generation:
reject("revocation state changed")
if current_resource_generation(observed_candidate) !=
B_now.resource_generation:
reject("resource generation changed")
if digest(current_authority_set(observed_candidate)) !=
B_now.authority_set_digest:
reject("authority set changed")
if !authorized_use_valid(handle, observed_candidate, B_now):
reject("use constraints violated")
if !effectuation_path_authorized(observed_candidate):
reject("alternate or unmediated effectuation path")
atomic {
assert current_protected_generation() == observed_generation
assert H(canonical(protected_current_basis(observed_candidate))) ==
H(canonical(B_now))
protected_consume_once(handle)
commit_effect(observed_candidate)
}
return SUCCESS
Das Expires 20 March 2027 [Page 24]
Internet-Draft State and Policy Continuity September 2026
14.6. Invalidate or Revalidate After Basis Change
function on_decision_basis_change(change):
if !change_can_affect_authorization(change):
record_non_load_bearing_change(change)
return
new_generation = advance_protected_generation()
publish_new_basis_identity(change, new_generation)
for pending in affected_pending_candidates(change):
mark_continuity_unknown(pending, new_generation)
if authoritative_compatibility_exists(pending, change):
attach_scoped_compatibility_evidence(pending)
else:
require_reevaluation(pending)
14.7. Handle a Concurrent Policy Update
function commit_if_generation_unchanged(candidate, handle, expected_generation):
atomic {
if current_protected_generation() != expected_generation:
return RETRY_WITH_CURRENT_BASIS
if !handle_still_applicable(candidate):
return REEVALUATE
protected_consume_once(handle)
commit_effect(candidate)
}
return SUCCESS
14.8. Crash and Recovery Handling
Das Expires 20 March 2027 [Page 25]
Internet-Draft State and Policy Continuity September 2026
function recover_finality(record):
if record.effect_committed:
mark_handle_consumed(record.handle)
return EFFECT_ALREADY_FINAL
if record.handle_consumed and !record.effect_committed:
# Deployment-specific recovery must not blindly replay.
return REQUIRE_IDEMPOTENT_RECOVERY_OR_MANUAL_RESOLUTION
if record.generation != current_protected_generation():
return REEVALUATE_UNDER_CURRENT_BASIS
return SAFE_TO_RETRY_FINALIZATION
14.9. Continuity-Finalization Flow Diagram
Candidate C + EH
|
v
exact C digest? ----- no ----> reject
|
yes
v
current basis B_now
|
+--> exact digest match -------- yes ---+
| |
+--> scoped compatibility CE --- yes ---+--> current-state checks
| |
+--> neither ---------------------------> re-evaluate / reject
|
v
capture generation G
|
v
atomic compare G == current?
/ \
no yes
| |
retry consume-once + commit
Figure 9: Detailed continuity-finalization flow
15. End-to-End Architecture
Das Expires 20 March 2027 [Page 26]
Internet-Draft State and Policy Continuity September 2026
+--------------------+
| Requester / Agent |
+---------+----------+
|
| Candidate Act C
v
+--------------------+ +---------------------+
| Policy / Decision |<-------| Policy, mapping, |
| Function | | reference state |
+---------+----------+ +----------+----------+
| |
| ALLOW under basis B17 | revisions advance
v v
+--------------------+ +---------------------+
| Execution Handle | | Current Basis B18 |
| H(C) + H(B17) | | protected epoch |
+---------+----------+ +----------+----------+
| |
+--------------+---------------+
|
v
=====================================================
FINALITY SINK
=====================================================
exact act binding
evaluated basis identity
current protected generation
revocation / ownership / mapping state
explicit compatibility OR re-evaluation
replay / use constraints
|
+-----+-----+
| ALL TRUE? |
+--+-----+--+
| |
no yes
| |
v v
REJECT PROTECTED COMMIT
|
v
EXTERNAL EFFECT
Figure 10: Decision-basis continuity through the Finality Sink
Das Expires 20 March 2027 [Page 27]
Internet-Draft State and Policy Continuity September 2026
Components above the boundary can compute, recommend, attest,
authorize, or cache decisions. They do not make stale state current
merely by preserving a valid permit. The Finality Sink controls
whether the authorization remains applicable to the state under which
the consequence will occur.
16. Attack Analysis
16.1. Policy Rollback
An attacker restores signed policy P16 after the authoritative state
advanced to P18. Signature verification succeeds because P16 is
authentic. A protected current-generation requirement causes the
rollback to fail because authenticity does not satisfy current
applicability.
16.2. Mapping Revision Substitution
Candidate Act C is evaluated using mapping M17. Before effectuation,
an intermediary changes the mapping target to M18 while keeping the
same logical mapping name. If authorization binds the content digest
or immutable revision of M17, M18 is not silently treated as the same
evaluation basis. The act requires an explicit compatibility proof
or re-evaluation.
16.3. Reference-State Rollback
Fresh attestation Evidence is appraised against an older but
authentic reference-value set that accepts a software state no longer
accepted by current policy. State-continuity verification requires
the applicable reference-state generation or equivalent authority
context, not merely a fresh nonce in the Evidence.
16.4. Stale Permit Replay
An authorization was valid before revocation and remains inside its
wall-clock expiry. An attacker presents it after the relevant
revocation generation has advanced. The Finality Sink rejects it
because the bound Decision Basis does not correspond to current
applicable state.
16.5. Split-Brain Authority State
Two enforcement nodes observe different policy heads or revocation
generations. Both can hold authentic state. A deployment requiring
a single authoritative head MUST define how the Finality Sink
determines the acceptable protected generation or consistency rule.
This document does not prescribe a consensus algorithm.
Das Expires 20 March 2027 [Page 28]
Internet-Draft State and Policy Continuity September 2026
16.6. Semantic-Equivalence Confusion
An attacker argues that M18 is "equivalent" to authorized mapping M17
while M18 changes a security-relevant rule. The Finality Sink does
not infer equivalence from labels, paths, or human-readable
descriptions. Cross-revision applicability requires an authoritative
compatibility statement or re-evaluation.
16.7. Crash and Snapshot Rollback
A virtual machine, enclave, policy service, or local database is
restored from a snapshot containing an older accepted generation. If
the Finality Sink relies only on snapshot-local state, old permits
can appear current again. Higher- assurance deployments SHOULD
anchor current generations in protected monotonic state, an external
authority, or another continuity mechanism not rolled back by the
same snapshot.
17. Bounded and Non-Bearer-Like Authorization
Sender-constraining a token can prevent an unauthorized party from
presenting it, but the legitimate sender can still hold a permit
whose decision basis is stale. The execution-finality binding
therefore includes both who or what can present authority and the
exact act and state basis for which that authority applies.
For a handle EH issued for Candidate Act C under Decision Basis B17,
the desired property is:
Finalize(C, B18, EH[C,B17]) = SUCCESS
only if B18 is the same applicable basis, an authoritative
compatibility relation exists, or C is re-evaluated under B18.
This property is complementary to proof-of-possession and sender-
constraining mechanisms such as OAuth DPoP [RFC9449].
18. The Alternate-Path Requirement
State continuity is ineffective if an alternate effectuation path can
bypass the continuity check. A legacy API, emergency interface,
direct device command, privileged database write, local actuator
path, or second resource server can recreate the same protected
consequence without observing the current policy head.
Das Expires 20 March 2027 [Page 29]
Internet-Draft State and Policy Continuity September 2026
+--> continuity check --> effect
Candidate Act ---+
+----------------------> effect
bypass
Figure 11: State-continuity bypass
Every mechanism capable of creating the protected consequence MUST
either pass through the Finality Sink or enforce an equivalent state-
continuity invariant.
19. Concurrency, Generations, and Policy Heads
Multiple policy updates and effectuation attempts can race.
Implementations MUST define what constitutes the authoritative
current state for the operation being finalized. A protected
generation, epoch, version vector, signed head, or equivalent
mechanism can provide this ordering.
current_policy_generation = g
evaluate(C) under g
advance policy to g+1
finalize(C, permit[g])
=> reject, re-evaluate, or prove explicit compatibility with g+1
A generation number by itself is not sufficient if an attacker can
reset the generation store. The continuity value must be protected
according to the threat model.
20. Applicability Beyond a Single Policy Engine
The continuity model applies wherever a security decision and a
protected effect are separated in time or by components. Examples
include agentic tool calls, payment or administrative operations,
workload admission, device assignment, network control, AI output
release, secure software lifecycle operations, data- purpose
enforcement, and industrial actuation.
Das Expires 20 March 2027 [Page 30]
Internet-Draft State and Policy Continuity September 2026
The exact Decision Basis differs by domain. For a payment it can
include limits, payee authorization, fraud state, and account status.
For a RATS-based decision it can include reference-value or
appraisal-policy identity. For AI output release it can include
requester scope, purpose grant, model/output class, and current
safety policy. For a device transition it can include resource
generation, ownership, lifecycle state, and destination
authorization.
21. Industrial Relevance and Complementary Standards Alignment
This section identifies protocol and deployment classes where state
continuity is relevant. The examples are alignment points only.
Nothing in this document asserts that any referenced product,
service, standard, vendor architecture, or deployment is vulnerable,
incomplete, or non-conformant. Existing identity, authorization,
attestation, confidential-computing, and policy products remain
useful inputs and enforcement components; the proposal adds a
separate continuity invariant for the interval between decision and
protected effectuation.
21.1. Agentic and Automated Tool Execution
Agent systems can obtain authorization before the final concrete
operation is effectuated. Revocation, user consent, account state,
routing mappings, and tool policy can change during that interval.
Exact-act binding and state-continuity checking can therefore be
composed with existing agent authorization, API security, tool-
permission, and policy systems rather than replacing them.
21.2. Microsoft Entra Continuous Access Evaluation
Microsoft Entra Continuous Access Evaluation (CAE) is an industrial
example of reevaluating access when critical events such as account
disablement, password change, explicit revocation, risk change, or
relevant Conditional Access state changes occur [MS-ENTRA-CAE]. CAE
demonstrates the practical value of reducing the gap between token
issuance and later enforcement. The continuity model in this
document is complementary: it generalizes the question to arbitrary
Decision Basis inputs and binds that applicability to an exact
Candidate Act at its protected effectuation boundary. No claim is
made that CAE should adopt this architecture or that CAE fails to
provide its documented protections.
Das Expires 20 March 2027 [Page 31]
Internet-Draft State and Policy Continuity September 2026
21.3. Amazon Verified Permissions and Cedar
Amazon Verified Permissions provides fine-grained application
authorization using Cedar policies and evaluates whether a principal
may perform an action on a resource in context [AWS-AVP]. Such a
policy decision point can serve as an authorization input to this
model. Where the protected operation occurs later, a deployment can
additionally bind the relevant policy-store state, policy generation,
or authenticated decision basis to the Candidate Act and re-establish
applicability at effectuation. This is an additional end-to-end
invariant, not a replacement for Verified Permissions or Cedar.
21.4. Google Cloud IAM Policy Enforcement
Google Cloud IAM supports allow and deny policy mechanisms for
controlling access to resources [GOOGLE-IAM-DENY]. In a deployment
using such policy systems, current IAM state can be one of the
authoritative inputs to the Decision Basis. The execution-finality
continuity model is complementary: it specifies how load-bearing
policy state can remain cryptographically or transactionally
connected to a later consequence when the decision and effect are
separated in time or across components.
21.5. OAuth and Resource-Server Enforcement
Rich Authorization Requests allow fine-grained authorization data to
be carried in OAuth messages [RFC9396]. DPoP can sender-constrain
access and refresh tokens [RFC9449]. These mechanisms can be useful
inputs to an execution-finality deployment. This document focuses on
the separate question of whether the state basis against which an
exact operation was authorized remains applicable when the resource
server or downstream sink makes that operation effective. The model
is complementary to OAuth and does not redefine OAuth token
semantics.
21.6. RATS and Attestation-Based Decisions
RATS separates Attesters, Verifiers, and Relying Parties and
describes freshness and appraisal concepts [RFC9334]. EAT provides
claims and freshness mechanisms for attestation tokens [RFC9711]. A
Relying Party can additionally require continuity of the policy,
reference state, or authorization mapping used to turn an Attestation
Result into permission for a consequential act. This document
therefore treats attestation as a valuable trust input, not as a
competing mechanism.
Das Expires 20 March 2027 [Page 32]
Internet-Draft State and Policy Continuity September 2026
21.7. NVIDIA Attestation and Arm Confidential Compute Architecture
NVIDIA documents an attestation suite for cryptographically verifying
GPU hardware and software integrity [NVIDIA-ATTEST]. Arm CCA and RME
provide hardware-backed isolation and attestation for Realm-based
confidential computing [ARM-CCA]. Such mechanisms can protect or
supply trust information for continuity state, validators, or
effectuation components in higher-assurance deployments. The
proposal here is complementary: it consumes or protects those trust
signals while asking whether the exact authorization basis remains
applicable to the exact consequence being committed.
21.8. SUIT and Anti-Rollback Patterns
RFC 9124 requires monotonically increasing manifest sequence numbers
in its firmware manifest information model to mitigate rollback under
the relevant firmware authority [RFC9124]. The continuity model in
this document is compatible with that pattern while applying it to
broader authorization state and to the interval between evaluation
and effectuation.
21.9. Confidential and High-Assurance Computing
Confidential-computing systems can protect code and data while policy
and lifecycle state remain mutable outside or across protected
components. A protected environment can therefore host the
continuity verifier, protected generation state, or Finality Sink.
The architecture is intentionally composable with such platforms and
does not require changes to a particular vendor's silicon, firmware,
or confidential-computing programming model.
22. Open Questions, Critique, and Corrections Invited
This document is offered for technical scrutiny. Criticism,
corrections, counterexamples, implementation experience, prior-art
pointers, and references to existing standards that already provide
equivalent properties are explicitly invited. The intent is to
refine or falsify the proposed invariant where evidence supports
doing so, not to characterize existing industrial or standards work
as deficient.
This document intentionally separates the continuity invariant from
any single token format, policy language, storage technology,
hardware vendor, cloud platform, or consensus mechanism. In
particular, review is requested on the following open questions:
Das Expires 20 March 2027 [Page 33]
Internet-Draft State and Policy Continuity September 2026
1. Do existing IETF, W3C, OpenID, confidential-computing, cloud-
authorization, interconnect, or vendor mechanisms already
provide an equivalent end-to-end invariant from authorization
under a particular Decision Basis through the first externally
effective consequence? If so, at what boundary and under what
threat model?
2. Is the adversary model stated in this document appropriate for
both the Baseline and High-Assurance Continuity Profiles? Which
components should be trusted, independently protected, or
explicitly considered compromisable?
3. Which mutable inputs are genuinely load-bearing for
authorization and therefore require effect-time binding or
protected re-establishment? Are policy generation, mapping
revision, revocation state, resource generation, authority set,
and reference state sufficient, excessive, or incomplete?
4. Can an authentic and unexpired authorization issued under basis
B17 safely remain usable after basis B18 becomes authoritative
without re-evaluation? If so, what machine-verifiable
compatibility relation is sufficient to establish that result?
5. Is exact content identity an appropriate safe default for policy
and mapping revisions? Where semantic equivalence is required,
can it be represented without requiring the Finality Sink to
make an open-ended semantic judgement?
6. What protected mechanism should establish the authoritative
current generation in deployments exposed to rollback, snapshot
restoration, compromised host software, split-brain authorities,
or recovery from crash?
7. Which alternate effectuation paths could bypass continuity
enforcement in real deployments, including administrative APIs,
recovery tooling, direct storage or device access, privileged
host paths, or independently reachable resource servers?
8. What atomicity, locking, compare-and-swap, transactional, or
equivalent property is required between the final continuity
observation and the protected commit when policy state can
change concurrently?
9. What latency, availability, cache-coherency, and state-
distribution costs would make the proposed invariant impractical
on a hot path, and which bounded-staleness or compatibility
techniques preserve the security objective without requiring a
synchronous global policy lookup for every operation?
Das Expires 20 March 2027 [Page 34]
Internet-Draft State and Policy Continuity September 2026
10. How should this architecture compose with existing industrial
mechanisms such as continuous access evaluation, fine-grained
cloud authorization, attestation, confidential computing, and
hardware-protected state without duplicating functions those
mechanisms already provide?
Concrete counterexamples are especially useful. A useful test is to
identify a system in which authorization is evaluated under basis
B17, basis B18 becomes authoritative before effectuation, and the
system can demonstrate that use of the old authorization cannot
create a consequence forbidden by B18 without relying on an
unverified semantic assumption. Evidence that an existing protocol
already closes that interval is equally useful and should be treated
as a correction or refinement to this document.
23. Questions to the IETF Community
The author requests community review not only of the mechanism but
also of whether the problem statement is correctly scoped for IETF
work. The following questions are intentionally direct. Negative
answers, references to existing equivalent mechanisms, and proposals
to narrow the work are useful outcomes.
1. Is there an existing IETF mechanism that already guarantees that
an authorization evaluated under Decision Basis B17 cannot create
a protected effect after B18 becomes authoritative unless B17
remains explicitly applicable? If so, which protocol and which
enforcement boundary provide that invariant?
2. Should current policy, revocation, reference-value, ownership, or
resource-generation state be represented directly in an
authorization object, reconstructed at the Resource Server or
Relying Party, or carried as separately verifiable Continuity
Evidence?
3. Can existing RATS epoch, freshness, reference-value, or
Attestation Result mechanisms express the required continuity
relation without defining a new protocol object, or is an
additional effectuation-time binding required?
4. For OAuth-protected operations, is the correct enforcement point
simply the Resource Server, or are there important deployments in
which the first externally effective consequence occurs below or
beyond the Resource Server and therefore requires a distinct
final enforcement boundary?
Das Expires 20 March 2027 [Page 35]
Internet-Draft State and Policy Continuity September 2026
5. For WIMSE-style multi-service chains, which workload should be
authoritative for the Decision Basis when identity, policy, or
authorization context changes across service boundaries? Is end-
to-end continuity achievable using existing workload credentials
and token-exchange patterns?
6. Would a minimal interoperable representation of Decision-Basis
identity, generation, compatibility, and consume-once state be
useful, or should this document remain purely architectural and
allow application protocols to define their own encodings?
7. Where bounded staleness is operationally necessary, what
properties are required so that a deployment can accept a bounded
window without silently converting stale authority into current
authority?
8. Should this work ultimately be Informational architecture, a Best
Current Practice, a Standards Track protocol element, or input to
one or more existing Working Groups?
9. Which IETF venue is the most appropriate home for further
discussion: SEC-DISPATCH, RATS, OAuth, WIMSE, SEAT, another
existing Working Group, or a separate effort? The author
explicitly invites guidance on disposition rather than presuming
Working Group ownership.
24. Relationship to Existing Work
24.1. RATS and EAT
RATS provides an architecture for Evidence, appraisal, Attestation
Results, and Relying Party decisions [RFC9334]. EAT specifies a
token format and requires a freshness mechanism [RFC9711]. This
document does not redefine those mechanisms. It addresses continuity
between the state basis of a decision and the later effect controlled
by a Relying Party or another protected sink.
24.2. SUIT
The SUIT architecture and manifest information model address secure
firmware update and include explicit rollback considerations
[RFC9019] [RFC9124]. The monotonic-sequence pattern is closely
related to one class of continuity mechanism. This document
generalizes the problem to mutable authorization and policy state,
where multiple independent state inputs can change after an allow
decision.
Das Expires 20 March 2027 [Page 36]
Internet-Draft State and Policy Continuity September 2026
24.3. TEEP
The TEEP architecture describes lifecycle management for Trusted
Applications in Trusted Execution Environments [RFC9397]. TEE
protection can be used to protect a policy generation, continuity
store, or Finality Sink, but a TEE is not required by the abstract
model.
24.4. OAuth Fine-Grained and Sender-Constrained Authorization
RFC 9396 supports fine-grained authorization details, while RFC 9449
constrains token use to a presenter proving possession of a
corresponding key [RFC9396] [RFC9449]. The state-continuity problem
can still arise when an otherwise valid exact or sender-constrained
authorization outlives the decision basis under which it was issued.
This document is intended as a complementary effectuation invariant,
not a replacement for OAuth.
24.5. Related Execution-Finality Internet-Drafts
This document is a focused member of a broader set of individual
execution-finality submissions. The architectural overview is
described in [DAS-PROTOCOL-LAYER]. Hardware-rooted enforcement is
discussed in [DAS-HW-EF]; agentic tool dispatch in [DAS-AGENT-EF];
attestation-bound execution finality in [DAS-RATS-EF]; purpose-bound
data use in [DAS-PURPOSE-EF]; and AI interoperability in
[DAS-INTEROP-EF]. The present document is intentionally narrower:
its load-bearing subject is continuity of mutable state and policy
between evaluation and effectuation.
These documents are individual Internet-Drafts and works in progress.
Cross-reference here indicates technical lineage and scope
separation; it does not imply IETF adoption, consensus, endorsement,
or standards status.
24.6. Public Implementations and Companion Engineering Material
Public repositories provide executable or explanatory material for
related portions of the execution-finality architecture. The general
architecture repository is [GITHUB-CORE-EF]. An attestation-bound
GPU and confidential-workload implementation is available at
[GITHUB-GPU-EF]. Challenge-bound AI interoperability hardening is
available at [GITHUB-HARDENED-INTEROP], and a purpose-execution-
finality validator is available at [GITHUB-PURPOSE-EF]. A separate
AI-interoperability implementation is available at
[GITHUB-INTEROP-EF].
Das Expires 20 March 2027 [Page 37]
Internet-Draft State and Policy Continuity September 2026
These repositories exercise related properties such as exact-act
binding, challenge or context binding, replay resistance, protected
validation, and Finality Sink enforcement. They are cited as
companion engineering material and are not represented as
implementing every state- and policy-continuity requirement in this
document unless a repository explicitly says so.
24.7. IETF Security-Area Relevance
The problem crosses attestation, authorization, secure software
lifecycle, protocol state, and high-consequence automated execution.
Discussion can therefore be relevant to the Security Area even where
no existing Working Group owns the complete cross-layer effectuation
invariant.
24.8. Potential IETF Discussion Venues and Scope Boundaries
This document is an Individual Submission and does not presume
adoption by any Working Group. Because the proposed invariant
crosses authorization, attestation, workload identity, protected
state, and effectuation, no single existing charter is assumed to own
the complete problem. The venues below are identified for
technically relevant review and routing, not as claims of charter
ownership.
SEC-DISPATCH Security Dispatch is the most natural initial venue for
determining disposition of cross-cutting Security Area work. Its
role includes assessing whether proposed work is appropriate for
the IETF, identifying overlap with existing protocols, and
directing work to an existing Working Group, a BOF or new charter,
AD sponsorship, or another outcome [IETF-SECDISPATCH].
RATS RATS is directly relevant where the Decision Basis contains
Evidence, Attestation Results, Endorsements, Reference Values,
freshness state, or epoch information. The present document's
additional question is whether those inputs remain applicable at
the later effectuation boundary. Review by RATS is therefore
particularly valuable for avoiding duplication and for testing
whether existing attestation constructs already express the
required continuity relation [IETF-RATS].
OAuth OAuth is relevant where a concrete operation is authorized
Das Expires 20 March 2027 [Page 38]
Internet-Draft State and Policy Continuity September 2026
through access tokens, Rich Authorization Requests, sender-
constrained credentials, transaction tokens, token status,
revocation, or automated-agent delegation. The OAuth Working
Group's current work explicitly includes complex delegation for
automated agents. The present document does not propose to
redefine OAuth; review is requested on whether existing or
emerging OAuth mechanisms already provide equivalent state
continuity through effectuation [IETF-OAUTH].
WIMSE WIMSE is relevant to workload identity, least-privilege access
across multiple service platforms, token exchange, and multi-hop
workload contexts. It is a useful venue for examining whether
Decision-Basis continuity must survive workload and
administrative-domain transitions, and whether existing workload
credentials can carry or reference the required state
[IETF-WIMSE].
SEAT SEAT is relevant when continuity evidence or attestation state
must be bound to a secure channel. Its charter focuses on binding
remote attestation to TLS or DTLS connections, so it is a
complementary review venue for transport-bound state rather than
an assumed home for general authorization finality [IETF-SEAT].
SCITT SCITT is relevant where signed statements, receipts,
transparency, provenance, or integrity of Decision-Basis material
are used as Continuity Evidence. SCITT's focus is trustworthy and
transparent digital supply chains, not general execution
authorization; accordingly, its relevance is primarily
compositional and evidentiary [IETF-SCITT].
SUIT SUIT provides an important standards precedent for
authenticated manifests, generations, and anti-rollback behavior.
Its charter is firmware-update-specific, so it is more naturally a
source of review and reusable continuity patterns than the primary
home for a general state-and-policy-continuity architecture
[IETF-SUIT].
SAAG The Security Area Advisory Group is an open forum for cross-
area security and privacy discussion and can provide broad
architectural feedback. SAAG is not a Working Group and does not
adopt or publish documents, so it is a discussion venue rather
than a document home [IETF-SAAG].
Das Expires 20 March 2027 [Page 39]
Internet-Draft State and Policy Continuity September 2026
The intended sequencing is therefore: seek technical criticism and
overlap analysis, use SEC-DISPATCH for routing if the work remains
cross-cutting, and pursue discussion in the relevant specialist
Working Groups where their existing charters cover particular
components. This document does not request that any named Working
Group expand its charter solely to accommodate the architecture.
25. Operational and Deployment Considerations
25.1. Choosing the Decision-Basis Scope
Binding every possible state variable can make authorization
unnecessarily fragile and expensive. Deployments SHOULD bind only
state whose change can alter the authorization outcome or the
protected consequence. The threat model SHOULD document which inputs
are load-bearing.
25.2. Digest Granularity
A digest of an entire policy repository is simple but can invalidate
unrelated operations whenever any rule changes. Merkle roots, scoped
policy objects, immutable policy modules, versioned decision graphs,
or other structures can reduce unnecessary invalidation while
retaining content-specific identity.
25.3. Latency
Re-evaluating a complete policy at every sink can be expensive.
Deployments can use protected current-generation checks, prevalidated
policy artifacts, local revocation summaries, authenticated
compatibility statements, or bounded caches. Such optimization MUST
NOT make stale cached state independently sufficient to create the
protected consequence.
25.4. Distributed State and Temporary Inconsistency
Large systems can temporarily disagree about the newest policy
revision. Deployments MUST define the acceptable consistency model
for protected effects. Some low-risk operations can tolerate bounded
staleness. High-consequence operations can require a strongly
current authority head or explicit recheck. This document does not
mandate one consistency model for all applications.
Das Expires 20 March 2027 [Page 40]
Internet-Draft State and Policy Continuity September 2026
25.5. Failure Handling
If a required continuity predicate cannot be established, high-
consequence deployments SHOULD keep the Candidate Act non-effective.
Missing policy-head state, unavailable revocation information,
ambiguous mapping revision, or rollback-detection failure SHOULD NOT
silently become authority to proceed.
26. Security Considerations
The security of the model depends on protecting both the effectuation
path and the state that defines current applicability. A perfect
content digest provides no continuity if an attacker can reset the
trusted current-generation register; a protected generation provides
no effectuation security if the protected consequence can bypass the
Finality Sink.
26.1. Compromised Requester
The requester is not assumed to provide truthful current policy,
mapping, epoch, or revocation state. The Finality Sink MUST obtain
security-critical continuity information from protected state or an
authority appropriate to the threat model.
26.2. Compromised Policy or Mapping Service
A compromised authoritative policy service can issue malicious
current state or compatibility statements. Higher-assurance
deployments MAY use threshold control, independent policy
authorities, transparency or audit mechanisms, hardware-protected
roots, or other separation of duties. This document does not claim
to protect against compromise of every ultimate authority.
26.3. Time-of-Check to Time-of-Use
This document directly addresses a TOCTOU class in which
authorization state can change after a decision. The Finality Sink
SHOULD minimize the interval between the last continuity check and
the protected commit. Where state can change concurrently, the check
and commit require atomicity, generation locking, compare-and-swap
semantics, transactional protection, or an equivalent invariant.
26.4. Rollback Protection
Policy generations, revocation generations, and other continuity
values SHOULD resist rollback, snapshot restoration, wraparound,
reset, and cross-domain reuse. An authentic old state MUST NOT
automatically be accepted as current state.
Das Expires 20 March 2027 [Page 41]
Internet-Draft State and Policy Continuity September 2026
26.5. Canonicalization and Content Identity
Policy and mapping objects MUST have an unambiguous representation
before a digest is treated as revision identity. Equivalent textual
encodings, ordering, whitespace, included files, external references,
environment variables, and dynamically resolved dependencies can
otherwise make a digest fail to represent the actual semantics used
during evaluation.
Where evaluation depends on external data, the binding SHOULD cover
the resolved load-bearing data or an authenticated root representing
it. Hashing a top-level policy file while leaving mutable referenced
data unbound does not provide the intended property.
26.6. Semantic Equivalence
Determining whether two arbitrary policies are semantically
equivalent can be computationally difficult, environment-dependent,
or undecidable in the general case. The security model therefore
does not require the Finality Sink to solve semantic equivalence.
Exact content identity is the safe default; explicit authoritative
compatibility or re-evaluation is the escape mechanism.
26.7. Revocation Race
A revocation can occur after an Execution Handle is issued and
immediately before effectuation. If revocation is load-bearing for
the operation, the Finality Sink MUST verify a current revocation
generation, protected revocation result, or equivalent state as part
of the protected commit.
26.8. Split-Brain and Partitioned Authorities
Network partitions can create multiple apparently current policy
heads. Systems MUST define whether effectuation fails closed, uses
quorum or consensus, accepts bounded staleness, or follows another
explicit rule. An attacker MUST NOT be allowed to choose whichever
reachable stale authority produces the desired authorization unless
that behavior is intentionally part of policy.
26.9. Non-Bypassability
Debug paths, emergency controls, administrative APIs, direct storage
writes, alternate resource servers, recovery tooling, and privileged
host interfaces require explicit analysis. Every path capable of
creating the protected consequence MUST preserve an equivalent
continuity invariant.
Das Expires 20 March 2027 [Page 42]
Internet-Draft State and Policy Continuity September 2026
26.10. Crash Consistency
Authorization consumption, policy-head observation, continuity
verification, and effectuation can span multiple components. A crash
MUST NOT restore an older policy generation or make a consumed stale
authorization reusable. Protected journals, monotonic counters,
idempotent recovery, transactional stores, or equivalent mechanisms
SHOULD be used where required by the threat model.
26.11. Fail-Closed Behavior and Denial of Service
Requiring current state can create availability pressure. Attackers
can target the policy-head service or continuity evidence path to
prevent protected actions. Availability engineering, replication,
and cached evidence can reduce this risk, but recovery mechanisms
MUST NOT silently convert "state unknown" into "state authorized" for
operations whose threat model requires current continuity.
27. Privacy Considerations
Decision-Basis records can reveal user identity, account status,
organizational relationships, policy membership, purpose, risk
classification, workload identity, location or jurisdiction, and
timing. Implementations SHOULD minimize retained state and SHOULD
avoid exposing raw policy inputs when a digest, keyed commitment,
selective-disclosure proof, or scoped continuity statement is
sufficient.
Stable policy or mapping digests can themselves become correlators
across systems. Deployments SHOULD consider whether global content
identifiers are necessary or whether domain-scoped commitments
provide the required enforcement property with less linkability.
28. IANA Considerations
This document has no IANA actions.
29. Conclusion
A valid authorization object can become stale without becoming
cryptographically invalid. Freshness, signatures, attestation,
sender-constraining, and fine-grained authorization remain necessary
mechanisms, but they answer different questions.
Das Expires 20 March 2027 [Page 43]
Internet-Draft State and Policy Continuity September 2026
State and policy continuity adds an effectuation-time invariant: the
exact act that becomes effective must still correspond to an
applicable decision basis, or it must be re-evaluated under the basis
that is current. A policy or mapping revision is identified by what
was actually evaluated, not merely by a mutable name or location, and
semantic equivalence is not silently inferred at the Finality Sink.
In short: authorization valid then is not automatically authority
now.
30. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
31. Informative References
[ARM-CCA] Arm, "Arm Confidential Compute Architecture", 2026,
<https://www.arm.com/architecture/security-features/arm-
confidential-compute-architecture>.
[AWS-AVP] Amazon Web Services, "What is Amazon Verified
Permissions?", 2026,
<https://docs.aws.amazon.com/verifiedpermissions/latest/
userguide/what-is-avp.html>.
[DAS-AGENT-EF]
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-HW-EF]
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 Expires 20 March 2027 [Page 44]
Internet-Draft State and Policy Continuity September 2026
[DAS-INTEROP-EF]
Das, S., "Secure and Privacy-Preserving AI
Interoperability under Article 6(7) of the European
Digital Markets Act: An Execution-Finality Architecture",
Work in Progress, Internet-Draft, draft-das-execution-
finality-ai-interoperability-04, September 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-ai-interoperability/>.
[DAS-PROTOCOL-LAYER]
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-EF]
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/draft-das-purpose-
execution-finality/>.
[DAS-RATS-EF]
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/draft-das-rats-
attestation-bnd-execution-finality/>.
[GITHUB-CORE-EF]
Das, S., "Execution-Finality Architecture for Machine-
Generated Acts", GitHub Repository Execution-Finality-
Architechture-for-AI-Machines-, 2026,
<https://github.com/sangmdas/Execution-Finality-
Architechture-for-AI-Machines->.
[GITHUB-GPU-EF]
Das, S., "Execution Finality for GPUs, AI Accelerators,
and Confidential Workloads", GitHub Repository Execution-
Finality-for-GPU-AI-Accelerators-and-Confidential-
Workloads, 2026, <https://github.com/sangmdas/Execution-
Finality-for-GPU-AI-Accelerators-and-Confidential-
Workloads>.
Das Expires 20 March 2027 [Page 45]
Internet-Draft State and Policy Continuity September 2026
[GITHUB-HARDENED-INTEROP]
Das, S., "Hardened Challenge-Bound Execution Finality for
AI Interoperability", GitHub Repository Hardened-
Challenge-Bound-Execution-Finality-for-AI-
Interoperability, 2026, <https://github.com/sangmdas/
Hardened-Challenge-Bound-Execution-Finality-for-AI-
Interoperability>.
[GITHUB-INTEROP-EF]
Das, S., "Secure and Privacy-Preserving AI
Interoperability for Third-Party Tools", GitHub
Repository Secure-and-Privacy-Preserving-AI-
Interoperability-for-Third-Party-Tools, 2026,
<https://github.com/sangmdas/Secure-and-Privacy-
Preserving-AI-Interoperability-for-Third-Party-Tools>.
[GITHUB-PURPOSE-EF]
Das, S., "Purpose Execution Finality Validator to Prevent
Data-Purpose Laundering in AI Systems", GitHub Repository
Purpose-Execution-Finality-Validator-to-Prevent-Data-
Purpose-Laundering-in-AI-Systems, 2026,
<https://github.com/sangmdas/Purpose-Execution-Finality-
Validator-to-Prevent-Data-Purpose-Laundering-in-AI-
Systems>.
[GOOGLE-IAM-DENY]
Google Cloud, "Deny access to resources: Identity and
Access Management", 2026,
<https://docs.cloud.google.com/iam/docs/deny-access>.
[IETF-OAUTH]
IETF, "Web Authorization Protocol (OAuth)", 2026,
<https://datatracker.ietf.org/wg/oauth/about/>.
[IETF-RATS]
IETF, "Remote ATtestation ProcedureS (RATS)", 2026,
<https://datatracker.ietf.org/group/rats/about/>.
[IETF-SAAG]
IETF, "Security Area Advisory Group (SAAG)", 2026,
<https://datatracker.ietf.org/group/saag/>.
[IETF-SCITT]
IETF, "Supply Chain Integrity, Transparency, and Trust
(SCITT)", 2026,
<https://datatracker.ietf.org/wg/scitt/about/>.
Das Expires 20 March 2027 [Page 46]
Internet-Draft State and Policy Continuity September 2026
[IETF-SEAT]
IETF, "Secure Evidence and Attestation Transport (SEAT)",
2026, <https://datatracker.ietf.org/group/seat/about/>.
[IETF-SECDISPATCH]
IETF, "Security Dispatch (SEC-DISPATCH)", 2026,
<https://datatracker.ietf.org/group/secdispatch/about/>.
[IETF-SUIT]
IETF, "Software Updates for Internet of Things (SUIT)",
2026, <https://datatracker.ietf.org/group/suit/about/>.
[IETF-WIMSE]
IETF, "Workload Identity in Multi System Environments
(WIMSE)", 2026,
<https://datatracker.ietf.org/wg/wimse/about/>.
[MS-ENTRA-CAE]
Microsoft, "Continuous access evaluation in Microsoft
Entra", 2026, <https://learn.microsoft.com/en-
us/entra/identity/conditional-access/concept-continuous-
access-evaluation>.
[NVIDIA-ATTEST]
NVIDIA, "NVIDIA Attestation", 2026,
<https://docs.nvidia.com/attestation/>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/rfc/rfc9019>.
[RFC9124] Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest
Information Model for Firmware Updates in Internet of
Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124,
January 2022, <https://www.rfc-editor.org/rfc/rfc9124>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
Das Expires 20 March 2027 [Page 47]
Internet-Draft State and Policy Continuity September 2026
[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
<https://www.rfc-editor.org/rfc/rfc9397>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[RFC9711] Lundblade, L., Selander, G., and C. Bormann, "The Entity
Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711,
April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.
Author's Address
Sangam Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 20 March 2027 [Page 48]