| Internet-Draft | State and Policy Continuity | September 2026 |
| Das | Expires 20 March 2027 | [Page] |
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.¶
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.¶
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 (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.¶
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
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.¶
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.¶
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.¶
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
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.
¶
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.¶
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.
¶
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)
¶
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)
¶
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)
¶
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)
¶
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.¶
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
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
¶
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.¶
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 |
+---------+
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.
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.
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.
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.
The system constructs a Candidate Act and a canonical representation of the security-relevant act parameters. Preparation MUST NOT itself create the protected consequence.¶
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.¶
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.¶
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.¶
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.¶
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())
¶
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())
¶
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
¶
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
¶
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
¶
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)
¶
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
¶
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
¶
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
+--------------------+
| 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
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
+--> continuity check --> effect
Candidate Act ---+
+----------------------> effect
bypass
Every mechanism capable of creating the protected consequence MUST either pass through the Finality Sink or enforce an equivalent state-continuity invariant.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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 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 is relevant where a concrete operation is authorized 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 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 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 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 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].¶
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].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶
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.¶