Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation

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

Table of Contents

1. Introduction

Security systems routinely issue authority that remains usable for some period of time. Access tokens, session credentials, signed permits, workload credentials, delegated grants, capability objects, and application-specific approvals permit useful decoupling between authorization and execution.¶

During that interval, circumstances can change. A principal can be disabled, an administrator can revoke a grant, a service principal can be suspended, a resource can change owner, a destination can be blocked, a purpose can be withdrawn, an attestation reference state can be invalidated, a fraud system can raise risk, or an emergency policy can prohibit an operation that was allowed seconds earlier.¶

The central question in this document is therefore:¶

        If authorization was valid at t0, but applicable authority is
        revoked or narrowed at t1, what MUST be true at t2 before the
        protected effect is allowed to occur?

The proposed answer is an execution-finality invariant: revocation that is authoritative before protected commit must be made load-bearing at the effectuation boundary. A previously valid authorization is not itself a right to outlive a later authoritative revocation.¶

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. Direct Question: What Threat Does This Architecture Solve?

The principal threat is not limited to stolen credentials, forged tokens, or expired authorization. The difficult case is a credential or permit that is authentic, unexpired, correctly sender-constrained where applicable, and legitimately held by the same principal that was authorized earlier.¶

          t0                         t1                         t2
          |                          |                          |
          | authorize exact act C    | revoke/narrow authority | effect C
          | under revocation R17     | advance to R18          |
          |--------------------------|--------------------------|
          |                          |                          |
          v                          v                          v
       Permit[C,R17]            Revocation R18            Finality Sink
       signature valid          is authoritative          must decide
       expiry valid                                      using current state

If the sink checks only the earlier signature, expiry, or possession proof, the act can survive the revocation window. The architecture described here makes the current applicable revocation state part of the final authorization predicate immediately before the consequence is committed.¶

The architecture therefore targets revocation lag at the protected consequence boundary, including stale-token use, stale introspection, cached allow decisions, policy narrowing, multi-hop delegation, crash recovery, network partition, alternate effectuation paths, and races between revocation and commit.¶

4. Motivating Scenario: Valid at Issuance, Revoked Before Effectuation

Consider a service or autonomous agent that prepares a consequential operation C. At time t0, principal A is authorized to perform C and a permit is issued. At t1, before C is externally effective, an authority disables A, revokes the grant, narrows the allowed destination set, or marks the relevant credential or workload as no longer acceptable.¶

The revocation does not necessarily alter the bytes or signature of the already-issued permit. A verifier that considers only issuance-time facts can therefore accept a permit that is authentic but no longer applicable.¶

The required property is not that every revocation must propagate instantaneously through every system. The required property is that the deployment explicitly defines the point at which revocation becomes authoritative for the protected consequence, and that an act cannot cross the protected commit after that point without satisfying the new state.¶

5. Problem Space

6. Threat Model and Assurance Scope

7. Design Goals and Non-Goals

The primary goal is to bind the applicability of revocation to the moment at which a protected consequence becomes effective. A revocation that is authoritative before protected commit MUST be capable of preventing a still-pending Candidate Act from completing when that revocation applies to the act.¶

This document does not define a universal identity system, universal revocation transport, universal policy language, new OAuth grant type, consensus protocol, blockchain, or globally synchronized clock. It also does not require every revocation to cancel every pending action. Deployments define the scope and semantics of revocation; the finality mechanism enforces those semantics at the protected boundary.¶

The document does not claim to roll back a consequence that has already become externally effective. Where compensating transactions are possible, they are a separate application concern. Revocation finality is primarily prospective with respect to acts that remain non-effective.¶

8. Prevention and Mitigation Property

The architecture distinguishes prevention from mitigation. A deployment can claim the prevention property described here only for a protected consequence whose effectuation paths are completely mediated by an enforcement boundary that obtains authoritative revocation state and couples the final revocation decision atomically, or under an equivalent protected ordering rule, to the protected commit.¶

        Revocation committed before protected effect
                    +
        authoritative current revocation state
                    +
        exact-act binding
                    +
        atomic/equivalent final check and commit
                    +
        no bypassing effectuation path
                    |
                    v
        stale authorization cannot produce the protected effect

Where a deployment accepts cached status with bounded staleness, performs only periodic checks, leaves alternate paths outside the Finality Sink, or cannot serialize revocation against effectuation, the mechanism can still reduce exposure and shorten the stale-authority window, but that is mitigation rather than the same prevention guarantee.¶

The architecture does not reverse a consequence that is already externally effective. Compensation, rollback of application state, recovery, and incident response remain separate concerns unless a particular application defines them as part of its protected commit model.¶

9. Existing Mechanisms and the Proposed Delta

Existing mechanisms solve important parts of revocation and continuous authorization. This document is not premised on those mechanisms being absent or defective. The comparison below identifies the additional invariant being examined.¶

10. 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 generated, queued, authorized, or validated while the requester still lacks the means to create the protected consequence without final enforcement.¶

Revocation Event: An authoritative change that withdraws, suspends, narrows, supersedes, or otherwise makes previously applicable authority no longer sufficient for one or more protected acts.¶

Revocation Authority: An authority whose revocation state is recognized by the deployment for the affected principal, credential, grant, policy, resource, destination, purpose, operation class, or other security-relevant scope.¶

Revocation Generation: A monotonically advancing epoch, generation, sequence, authenticated status root, or equivalent protected value identifying revocation state.¶

Revocation Cutoff: The deployment-defined ordering point after which a particular revocation is authoritative for a protected act.¶

Revocation Basis: The security-relevant revocation state against which an authorization or Candidate Act was evaluated.¶

Revocation Evidence: Protected evidence establishing the applicable revocation state, or the relationship between issuance-time and effectuation-time revocation state.¶

Execution Handle: Narrowly scoped authorization bound to a Candidate Act, its relevant revocation basis, and authorized-use constraints. Possession of the handle is not intended to confer authority after an applicable revocation.¶

Finality Sink: The protected functional boundary controlling the first operation that makes the Candidate Act externally effective. It verifies or re-establishes revocation applicability immediately before protected commit.¶

Protected Commit: The serialization or transition point at which the protected act becomes externally effective or irreversibly enters a consequence-bearing subsystem under the deployment's model.¶

11. Revocation Classes

12. Revocation-Binding Model

Let C contain the concrete security-relevant Candidate Act parameters. Let R_eval represent the revocation basis observed when the act is authorized.¶

        C = (subject, operation, object, destination, parameters,
             purpose, nonce, constraints)

        R_eval = (principal_rev_gen,
                  credential_rev_gen,
                  grant_rev_gen,
                  resource_rev_gen,
                  trust_rev_gen,
                  policy_rev_gen)

        D_C = H(Encode(C))
        D_R = H(Encode(R_eval))

        EH = Protect(D_C, D_R, UseConstraints, Freshness,
                     IssuerContext, SingleUseState)

A deployment need not use every field. It MUST include or re-establish each revocation dimension whose change can make the specific Candidate Act unauthorized.¶

The semantic rule is:¶

        Authorized(C, R17) does not imply Authorized(C, R18)

        when an applicable revocation represented by R18 invalidates,
        suspends, narrows, or supersedes authority for C.

C = canonical security-relevant Candidate Act

R_eval = (
    principal_rev_gen,
    credential_rev_gen,
    grant_rev_gen,
    resource_rev_gen,
    trust_rev_gen,
    policy_rev_gen
)

R_now = authoritative current revocation basis

D_C = H(Encode(C))
D_R = H(Encode(R_eval))

EH = Protect(
       D_C,
       D_R,
       RevocationScope,
       UseConstraints,
       Freshness,
       IssuerContext,
       SingleUseState)

Applies(E_rev, C, EH) :=
       ScopeMatches(E_rev.scope, C, EH.revocation_scope)
   AND SubjectOrCredentialMatches(E_rev, C, EH)
   AND OperationPurposeResourceMatches(E_rev, C)
   AND EventAuthoritativeForScope(E_rev)
   AND EventGenerationNotRolledBack(E_rev)

Survives(C, R_eval, R_now, SE) :=
       SurvivalEvidenceAuthentic(SE)
   AND SurvivalEvidenceAuthoritative(SE)
   AND ExactCandidateOrClassBound(SE, C)
   AND BasisTransitionMatches(SE, R_eval, R_now)
   AND UseConstraintsSatisfied(SE, C)
   AND FreshnessValid(SE)

RevocationContinuityValid(C, EH, R_now, SE) :=
       HandleIntegrityValid(EH)
   AND ExactActBinding(EH, C)
   AND HandleUseValid(EH, C)
   AND FreshnessValid(EH)
   AND RevocationScopeCurrent(EH, C, R_now)
   AND (
          SameRelevantRevocationBasis(EH, R_now)
          OR Survives(C, EH.revocation_basis, R_now, SE)
       )
   AND NoApplicableRevocationCommittedBeforeEffect(C, R_now)
   AND EffectuationPathAuthorized(C)

Let:

CommitRev(E_rev)  = authoritative commit of revocation event E_rev
CommitEff(C)      = protected effect commit for Candidate Act C

If:
    CommitRev(E_rev) ≺_S CommitEff(C)
AND Applies(E_rev, C, EH)

then:
    C MUST be re-authorized under the resulting basis
    OR an explicit valid Survival rule MUST apply
    OR C MUST remain non-effective.

Effective(C)
    =>
RevocationContinuityValid(C, EH, R_now, SE) = TRUE

Strict prevention:

NOT RevocationContinuityValid(C, EH, R_now, SE)
    =>
NOT Effective(C)

Race-specific form:

CommitRev(E_rev) ≺_S CommitEff(C)
AND Applies(E_rev, C, EH)
AND NOT Survives(C, R_eval, R_now, SE)
    =>
NOT Effective(C)

13. Finality Predicate and Safety Invariant

Immediately before protected commit, the Finality Sink evaluates a predicate Phi over the observed Candidate Act, Execution Handle, current revocation state, and any explicit survival or compatibility evidence.¶

        Phi(C, EH, R_now, RE) =
             ExactActBinding
          AND HandleIntegrityValid
          AND HandleUseValid
          AND FreshnessValid
          AND PrincipalNotEffectivelyRevoked
          AND CredentialNotEffectivelyRevoked
          AND GrantNotEffectivelyRevoked
          AND ResourceStateApplicable
          AND PurposeAndOperationStillAllowed
          AND TrustStateApplicable
          AND RevocationOrderingValid
          AND RevocationEvidenceValid
          AND EffectuationPathAuthorized

The safety invariant is:¶

        Effective(C) => Phi(C, EH, R_now, RE) = TRUE

It is insufficient that Phi was true at issuance time. Where revocation is load-bearing, the sink MUST establish current applicability as part of, or atomically adjacent to, the protected commit.¶

The detailed predicates for revocation applicability, survival evidence, serialization order, and strict prevention are specified in the formal subsections of <xref target="formal-model"/>. In particular, a handle that remains cryptographically valid after an applicable revocation is not sufficient authority to effect the act.¶

14. Revocation Ordering and the Race with Effectuation

Revocation and effectuation can occur concurrently. A secure design therefore needs an ordering rule rather than relying only on wall-clock timestamps. One implementation can serialize both through a protected generation or transaction log; another can use compare-and-swap, a monotonic counter, quorum state, or an equivalent linearizable rule.¶

          Case A: revocation wins the serialization race

          Commit(R18) -------------------+
                                         |
                                         v
                                  Finalize(C, EH[R17])
                                         |
                                         +-- reject / re-authorize /
                                             prove explicit survival

          Case B: protected effect commits first

          Commit(Effect C) --------------+---- then Commit(R18)
                                         |
                                         +-- C is already effective;
                                             R18 governs later acts

          Ordering rule:

          If Commit(Revocation R18) precedes Commit(Effect C):
              C MUST satisfy R18 or remain non-effective.

A deployment SHOULD document what constitutes the authoritative revocation commit and the protected effect commit. Ambiguous ordering can otherwise produce inconsistent security decisions under concurrency.¶

t0                         t1                         t2
|                          |                          |
| authorize C under R17    | applicable revocation   | Finality Sink
| EH binds C + R17         | commits as R18          | asked to effect C
|--------------------------|--------------------------|
                                                       |
                                                       v
                                               R18 MUST govern

A cryptographically valid EH[R17] is not sufficient after an
applicable R18 commits before protected effect.

Finalizer                         Revocation Authority
    |                                      |
    | read R17 / generation 17             |
    | verify C under R17                    |
    |                                      |
    |                         commit R18 ---+
    |                                      |
    | enter atomic protected commit         |
    | assert generation == 17  ---- FAIL    |
    |                                      |
    +---- reject / reload R18 / re-authorize

The final assertion closes the verify-then-revoke race.

15. Revocation-Finality Enforcement Architecture

          +------------------+        +---------------------------+
          | Requester /      |        | Revocation / Policy       |
          | Agent / Workload |        | Authority                 |
          +--------+---------+        +-------------+-------------+
                   |                                |
                   | Candidate Act C                | Rg / events / roots
                   v                                v
          +------------------+        +---------------------------+
          | Authorization    |------>| Protected Current-State   |
          | / Policy Check   |        | View or Status Source     |
          +--------+---------+        +-------------+-------------+
                   |                                |
                   | EH[C,Rg]                       | R_now
                   v                                v
          +------------------------------------------------------+
          |                    FINALITY SINK                      |
          |  exact-act binding + current revocation + ordering  |
          |  + consume-once + non-bypassable protected commit   |
          +---------------------------+--------------------------+
                                      |
                              only if predicate TRUE
                                      v
                              +---------------+
                              | External      |
                              | Effect        |
                              +---------------+

The diagram is functional rather than topological. The authorization service, current-state source, and Finality Sink MAY be co-located or distributed. The security requirement is that the requester cannot bypass the final predicate and that the revocation state used at commit is authoritative under the deployment's ordering rule.¶

Candidate C + EH[R_eval]
          |
          v
+---------------------------+
| Verify EH integrity       |
| Verify exact act          |
| Verify freshness/use      |
+-------------+-------------+
              |
              v
+---------------------------+
| Read authoritative R_now  |
| under protected ordering  |
+-------------+-------------+
              |
        basis changed?
          /       \
        no         yes
        |           |
        |      +----v------------------+
        |      | applicable revocation?|
        |      +----+------------------+
        |           |
        |       yes / no
        |         /   \
        |        /     +----> continue if irrelevant
        |       v
        |   valid survival evidence?
        |       / \
        |      no  yes
        |      |    |
        |   REJECT  |
        +------\----+
                v
       +---------------------+
       | protected atomic    |
       | generation recheck  |
       | consume-once        |
       | commit effect       |
       +---------------------+

16. State Machine

          +-----------+
          | PROPOSED  |
          +-----+-----+
                |
                | authorize under revocation basis Rg
                v
          +------------------+
          | NON-EFFECTIVE    |
          | AUTHORIZED       |
          +--------+---------+
                   |
                   | observe current revocation state
                   v
          +--------------------+
          | APPLICABLE         |
          | REVOCATION CHANGE? |
          +----+----------+----+
               |          |
              yes         no
               |          |
               v          v
       REJECT / REAUTHORIZE   PROTECTED COMMIT
       / PROVE SURVIVAL             |
                                    v
                               +----------+
                               | EFFECTIVE|
                               +----------+

17. Solution Overview

18. Illustrative Pseudocode

The following pseudocode is non-normative and independent of token format or revocation transport. It separates authorization-time binding, revocation-state ingestion, applicability evaluation, explicit survival handling, protected finalization, state-change invalidation, effectuation-path coverage, and crash recovery.¶

function authorize_and_bind(candidate):
    C = canonical_security_relevant_act(candidate)

    R_eval = authoritative_revocation_snapshot(C)

    if R_eval.status == UNKNOWN:
        reject_or_apply_explicit_bounded_staleness_profile()

    decision = policy_evaluate(C, R_eval)

    if decision != ALLOW:
        reject()

    return protect_handle(
        act_digest          = H(C),
        revocation_basis    = R_eval.identity_or_generation,
        revocation_scope    = decision.revocation_scope,
        subject             = C.subject,
        credential_id       = C.credential_id_if_applicable,
        grant_id            = decision.grant_id_if_applicable,
        use_constraints     = decision.use_constraints,
        nonce               = secure_random(),
        expiry              = bounded_expiry(),
        single_use          = true)

function accept_revocation_update(event):
    if !authenticate_revocation_event(event):
        reject_event("invalid authenticity")

    if !event.scope_is_authoritative_here:
        reject_event("wrong revocation authority")

    current = protected_current_generation(event.scope)

    if event.generation < current:
        reject_event("rollback attempt")

    if event.generation == current
       and !event_is_idempotent_duplicate(event):
        reject_event("conflicting same-generation event")

    protected_atomic {
        append_authoritative_revocation_event(event)
        advance_revocation_generation_if_needed(event)
        invalidate_affected_pending_cache_entries(event)
    }

    return ACCEPTED

function authoritative_revocation_snapshot(candidate):
    snapshot = {
        principal: current_principal_revocation(candidate.subject),
        credential: current_credential_revocation(
                        candidate.credential_id_if_applicable),
        grant: current_grant_revocation(
                   candidate.grant_id_if_applicable),
        resource: current_resource_revocation_state(candidate.object),
        trust: current_trust_revocation_state(candidate.subject),
        policy: current_policy_revocation_generation(candidate)
    }

    if any_required_dimension_unknown(snapshot, candidate):
        return UNKNOWN

    snapshot.identity_or_generation =
        protected_digest_or_generation(snapshot)

    return snapshot

function applicable_revocations(candidate, handle, R_now):
    applicable = []

    for event in R_now.committed_events:
        if !event_authoritative_for_scope(event):
            continue

        if !scope_matches(
                event.scope,
                handle.revocation_scope,
                candidate):
            continue

        if !subject_credential_grant_resource_matches(
                event, candidate, handle):
            continue

        if !operation_or_purpose_matches_if_scoped(
                event, candidate):
            continue

        applicable.append(event)

    return applicable

function validate_survival(
        candidate,
        handle,
        R_now,
        survival_evidence):

    if survival_evidence == NONE:
        return FALSE

    if !verify_survival_evidence_integrity(survival_evidence):
        return FALSE

    if !survival_authority_trusted(
            survival_evidence.issuer,
            handle.revocation_scope):
        return FALSE

    if !survival_evidence_binds_exact_candidate_or_class(
            survival_evidence,
            candidate):
        return FALSE

    if !survival_evidence_matches_transition(
            survival_evidence,
            handle.revocation_basis,
            R_now.identity_or_generation):
        return FALSE

    if !survival_evidence_use_constraints_valid(
            survival_evidence,
            candidate):
        return FALSE

    if !survival_evidence_fresh(survival_evidence):
        return FALSE

    return TRUE

function finalize(
        observed_candidate,
        handle,
        survival_evidence = NONE):

    begin_protected_finality_section()

    C = canonical_security_relevant_act(observed_candidate)

    if !verify_handle_integrity(handle):
        reject("invalid handle")

    if handle.expired or handle.consumed:
        reject("expired or consumed handle")

    if H(C) != handle.act_digest:
        reject("exact-act mismatch")

    R_now = authoritative_revocation_snapshot(C)

    if R_now == UNKNOWN:
        fail_closed_unless_explicit_staleness_profile_allows()

    applicable = applicable_revocations(C, handle, R_now)

    basis_same =
        (R_now.identity_or_generation == handle.revocation_basis)

    if !basis_same:
        if applicable is not empty:
            if !validate_survival(
                    C, handle, R_now, survival_evidence):
                reject_or_reauthorize(
                    "applicable revocation committed")
        else:
            # Basis changed, but no relevant revocation applies to C.
            if !authoritative_transition_irrelevant_to_candidate(
                    handle.revocation_basis, R_now, C):
                reject_or_reauthorize(
                    "basis changed without proof of irrelevance")

    observed_generation = R_now.identity_or_generation

    atomic {
        R_commit = authoritative_revocation_snapshot(C)

        assert R_commit != UNKNOWN

        assert R_commit.identity_or_generation ==
               observed_generation

        assert no_new_applicable_revocation(
            C, handle, R_commit,
            since_generation=observed_generation)

        assert effectuation_path_authorized(C)

        consume_once(handle)

        commit_protected_effect(C)
    }

    return EFFECT_COMMITTED

function on_revocation_commit(event):
    affected = pending_candidates_potentially_affected_by(event)

    for pending in affected:
        mark_revalidation_required(
            pending.handle_id,
            new_generation=event.generation)

        if event_definitively_revokes(pending.candidate):
            mark_non_effective(pending.handle_id)

    publish_protected_generation(event.scope, event.generation)

function verify_revocation_path_coverage(
        consequence,
        effectuation_path_inventory):

    for path in paths_capable_of(consequence,
                                 effectuation_path_inventory):

        if path.crosses_finality_sink_with_current_revocation:
            continue

        if path.enforces_equivalent_revocation_finality:
            continue

        return CoverageFailure(
            reason="revocation-bypass path",
            witness=path)

    return COVERAGE_VALID

function recover(candidate_id):
    state = protected_commit_state(candidate_id)

    if state == EFFECTIVE:
        return DO_NOT_REPLAY

    if state == COMMITTING:
        result = resolve_atomic_commit(candidate_id)

        if result == EFFECT_COMMITTED:
            return DO_NOT_REPLAY

        # If no effect committed, revocation state may have changed
        # during the crash. Re-enter finalization from fresh state.
        return REVALIDATE_FROM_CURRENT_REVOCATION_STATE

    if state == PENDING:
        return REVALIDATE_FROM_CURRENT_REVOCATION_STATE

    return FAIL_CLOSED

19. Push, Pull, and Mirrored Revocation State

20. Selective and Partial Revocation

Revocation need not be all-or-nothing. An authority can revoke one destination, purpose, tool, operation class, resource generation, or delegation edge while allowing unrelated acts to proceed. For that reason a single global "revoked" boolean can be too coarse for complex systems.¶

A revocation-finality implementation SHOULD bind or reconstruct sufficient scope to determine whether the specific Candidate Act is affected. False equivalence between "principal remains active" and "this act remains authorized" must be avoided.¶

Current revocation events:

  E1: revoke credential K7
  E2: revoke grant G9 only for resource R-B
  E3: suspend principal P4 for operation=TRANSFER

Pending acts:

  C1: P4 / K7 / G8 / READ R-A
  C2: P4 / K9 / G9 / WRITE R-B
  C3: P4 / K9 / G3 / TRANSFER R-C

Applicability:

  E1 -> C1
  E2 -> C2
  E3 -> C3

Authenticity alone is not enough; revocation scope must match C.

21. Multi-Hop Delegation and Agent Chains

In distributed agent or workload chains, upstream authority can be transformed into downstream credentials or queued actions. A revocation at the original authority may not automatically cancel all derived objects unless the derivation chain preserves a revocation relationship.¶

        User / Authority
              |
              v
          Workload A ----delegates----> Workload B
              |                            |
              |                            v
              |                        Tool / API
              |                            |
              +------- revocation --------+
                                           |
                                           v
                                      Finality Sink

A deployment MAY propagate revocation generations, grant identifiers, parent authority references, or equivalent derivation metadata so the final sink can determine whether an upstream revocation invalidates the concrete downstream act.¶

22. Alternate Effectuation Paths

Revocation finality fails if the protected operation can be completed through a route that omits the final revocation check. Alternate resource servers, administrative APIs, asynchronous queues, direct database writes, recovery tools, legacy interfaces, local device APIs, privileged host calls, and emergency controls require explicit analysis.¶

Every path capable of creating the protected consequence MUST either converge on the same Finality Sink or preserve an equivalent revocation-finality invariant.¶

Primary path:
   C -> Finality Sink -> current revocation check -> EFFECT

Alternate path:
   C -> admin / queue / recovery / direct API ------> EFFECT

If the alternate path can effect C without equivalent current
revocation enforcement, revocation prevention is not consequence-wide.

23. Caching and Bounded Staleness

Cached authorization and introspection results are often necessary for availability and scale. RFC 7662 explicitly requires designers to consider the security and performance tradeoffs of caching token-state information [RFC7662]. This document does not prohibit caching.¶

A high-assurance profile SHOULD treat the maximum accepted staleness interval as a security parameter. For some operations the acceptable value can be zero at the protected commit; for lower-consequence operations a bounded interval can be an intentional policy choice. The deployment SHOULD make that choice observable and testable.¶

24. Crash Consistency and Recovery

A crash between observing revocation state and committing an effect can reopen the race. Recovery MUST NOT restore an older revocation generation, resurrect a consumed handle, or complete an operation under a pre-crash allow decision without re-establishing the required invariant.¶

Protected journals, monotonic counters, transactional stores, idempotent commit records, compare-and-swap, or equivalent mechanisms can be used according to the deployment.¶

State transitions for one Candidate Act:

PENDING
   |
   | final checks pass
   v
COMMITTING
   |
   +---- protected consume marker
   |
   +---- protected effect commit
   v
EFFECTIVE

Crash cases:

before consume      -> safe to retry after revalidation
after consume,
before effect       -> recover transactionally; do NOT blindly replay
after effect commit -> treat as effective; do NOT repeat C

25. Attack Analysis

26. Relationship to OAuth Revocation and Introspection

OAuth 2.0 Token Revocation [RFC7009] defines an endpoint through which a client can request invalidation of a token and, where applicable, related authorization. OAuth 2.0 Token Introspection [RFC7662] defines how a protected resource can ask an authorization server about the current active state and metadata of a token.¶

Those mechanisms are directly relevant and can supply inputs to this architecture. This document does not redefine their wire formats or semantics. The additional question is architectural: after token status is known, what prevents a previously instantiated or delegated Candidate Act from becoming effective through a later boundary that no longer consults the applicable revocation state?¶

In deployments where the OAuth Resource Server is itself the complete, non-bypassable consequence boundary and performs sufficiently current status checks, the Resource Server can satisfy the Finality Sink role and no additional component is required. The model is intended to identify when that property does or does not hold.¶

27. Relationship to Sender-Constrained Tokens

Sender-constraining mechanisms such as mutual-TLS-bound access tokens and DPoP reduce the value of stolen bearer tokens [RFC8705] [RFC9449]. They are complementary to revocation finality. A correctly sender-constrained token can still be revoked while held by its legitimate sender; therefore proof of possession and current applicability answer different questions.¶

28. Relationship to RATS and Attestation

The RATS architecture [RFC9334] separates Evidence, Attestation Results, appraisal policy, and Relying Party decisions. EAT [RFC9711] provides a token format for attestation claims and requires freshness mechanisms appropriate to its use. Revocation can affect endorsements, reference values, keys, software acceptability, or the authority that interprets attestation state.¶

This document does not modify RATS. It asks how a change in trust acceptability becomes load-bearing when a consequential operation is pending after an earlier successful appraisal. A fresh attestation result and a current revocation check can be combined as inputs to the finality predicate.¶

29. Relationship to WIMSE

WIMSE addresses workload identity, credentials, and security context across multi-service environments. Revocation finality is relevant where a workload credential or delegated security context has already caused a downstream Candidate Act to be instantiated before the originating workload or delegation is revoked.¶

This document does not propose to change workload identifiers or credential formats. It asks whether revocation relationships and current-state semantics need to survive the multi-hop path to the consequence boundary.¶

30. Complementary Industrial Alignment

Industry systems already provide important dynamic-access and trust mechanisms. Microsoft Entra Continuous Access Evaluation [MS-CAE] supports rejection of otherwise unexpired tokens after critical events. Amazon Verified Permissions and Cedar [AWS-VERIFIED-PERMISSIONS] provide fine-grained externalized authorization- policy evaluation. Google Cloud IAM [GOOGLE-IAM-DENY] supports centrally managed deny policy controls. NVIDIA attestation [NVIDIA-ATTEST] and Arm CCA [ARM-CCA] provide complementary protected-compute and attestation mechanisms that can supply trust inputs or host protected state.¶

These examples are cited because they demonstrate practical industry interest in dynamic authorization, policy change, continuous evaluation, and protected trust. This document does not assert that any named product is insecure, incomplete, vulnerable, non-conforming, or required to implement this architecture. A named platform can already satisfy some or all of the described properties in a particular deployment.¶

The proposed contribution is a vendor-neutral question and invariant that can be tested across systems: once a revocation is authoritative, can any still-pending protected act become externally effective solely on the strength of the older authorization?¶

31. Deployment Patterns

32. Performance and Availability

A design that performs a remote authorization-server round trip before every low-latency effect can be impractical. The architecture therefore separates the invariant from a particular implementation. Protected local generations, authenticated status roots, event streams with gap detection, short-lived cached state, and hardware-local comparisons can move most work off the hot path.¶

Implementations SHOULD publish the effective revocation-latency bound relevant to the protected operation, including event propagation, cache lifetime, replication lag, protected-state update, and finality-check latency. A benchmark that reports only local cryptographic verification without propagation delay does not characterize end-to-end revocation responsiveness.¶

33. Required Classes of Test Vectors

A concrete profile or implementation SHOULD test at least the following cases:¶

• authorization and effect under the same revocation generation: succeed;¶
• principal revoked before finalization: reject;¶
• grant narrowed so the exact act is no longer permitted: reject;¶
• unrelated revocation that does not apply to the act: succeed if policy says so;¶
• stale but correctly signed permit after revocation: reject;¶
• replayed old revocation state: reject;¶
• lost or reordered revocation event: fail according to the defined continuity rule;¶
• revocation and effect racing concurrently: produce the defined serialized result;¶
• crash after status check but before effect: recover without reviving stale authority;¶
• alternate effectuation path: demonstrate equivalent enforcement or identify the gap.¶

34. Questions to the IETF Community

Criticism, corrections, counterexamples, operational experience, prior-art pointers, and evidence that an existing IETF mechanism already provides an equivalent invariant are explicitly invited. Negative answers and recommendations to narrow the work are useful outcomes.¶

1. Do existing OAuth revocation, introspection, transaction-token, or continuous-access patterns already guarantee that a revocation committed before a protected effect prevents that effect, including asynchronous or multi-hop cases?¶
2. When a Resource Server accepts a request and hands work to a queue, database, payment rail, device API, or downstream workload, where should revocation stop being relevant and where should it remain load-bearing?¶
3. Is a protected monotonic revocation generation useful as a common abstraction across token, workload, attestation, and application-policy systems, or is that abstraction too broad?¶
4. Should revocation state be carried in the authorization object, re-established at the sink, or support both models?¶
5. What ordering primitive is appropriate for the race between revocation and effectuation without requiring a globally synchronized clock?¶
6. How should bounded staleness be represented so that deployments can distinguish an intentional availability tradeoff from a high-assurance current-state guarantee?¶
7. In WIMSE-style multi-service chains, what minimum derivation information is needed so an upstream grant revocation can invalidate a downstream pending act without creating excessive coupling?¶
8. For RATS-based systems, are existing endorsement/reference-value freshness and appraisal mechanisms sufficient to express trust-state revocation through the final consequential action?¶
9. Which alternate effectuation paths are most likely to defeat revocation in real systems even when token-level revocation itself works correctly?¶
10. Does this architecture duplicate an existing industrial or standards mechanism in full? If so, reviewers are specifically invited to identify the mechanism and the exact boundary at which it provides the same invariant.¶
11. Should this work remain Informational, become a BCP/problem statement, define an interoperable status/generation profile, or be folded into existing OAuth/WIMSE/RATS work?¶
12. Which current IETF venue is the best place for further discussion: OAuth, WIMSE, RATS, DISPATCH, SAAG, or another group?¶

35. Potential IETF Discussion Venues and Scope Boundaries

36. Relationship to Other Execution-Finality Internet-Drafts

This document is a focused member of a broader execution-finality discussion. The general architecture is described in [DAS-CORE-EF]. Hardware-rooted deployment is discussed in [DAS-HW-EF]. Agentic tool dispatch is discussed in [DAS-AGENT-EF]. Attestation-bound finality is discussed in [DAS-RATS-EF]. Purpose-bound release is discussed in [DAS-PURPOSE-EF]. Device/AI interoperability is discussed in [DAS-INTEROP-EF]. State and policy continuity is discussed in the companion [DAS-STATE-CONTINUITY] document.¶

The present draft intentionally isolates revocation rather than repeating all of those domains. Its contribution is the ordering and enforcement rule for authority that changes after issuance but before protected effectuation.¶

37. Public Implementations and Companion Engineering Material

Public repositories associated with the execution-finality work provide runnable or explanatory material for exact-act binding, single-use finality, agent interoperability, purpose-finality validation, and protected infrastructure deployment. Relevant resources include [GITHUB-CORE-EF], [GITHUB-GPU-EF], [GITHUB-HARDENED-INTEROP], [GITHUB-PURPOSE-EF], and [GITHUB-INTEROP-EF].¶

These repositories are companion engineering material. Their inclusion does not assert that every repository already implements every revocation-finality requirement in this document. A dedicated conformance harness for the present profile would need to test the race, propagation, rollback, and multi-hop cases listed above.¶

38. Security Considerations

The security of revocation finality depends on both current-state integrity and consequence-path completeness. A perfect revocation service is ineffective if the protected action can bypass the sink; a perfect sink is ineffective if an attacker can reset the revocation generation it relies on.¶

39. Privacy Considerations

Revocation state can expose sensitive relationships and operational facts. A global revocation identifier can become a correlator across services. Implementations SHOULD minimize persistent identifiers, avoid exposing raw policy context when a scoped status assertion is enough, and separate operational telemetry from authorization state where feasible.¶

Push-based revocation systems can also reveal user or workload activity to subscribers. Subscription scope, event minimization, retention, and authorization should therefore be treated as privacy-sensitive design choices.¶

40. Criticism, Corrections, and Review Invited

This document is intentionally presented for adversarial technical review. Reviewers are invited to identify incorrect assumptions, existing mechanisms that already provide the same property, deployment cases where the proposed boundary is unnecessary, unmodeled bypass paths, interoperability problems, privacy costs, latency costs, or terminology that conflicts with established IETF usage.¶

In particular, the author welcomes concrete counterexamples showing that a revocation committed before effectuation can already be guaranteed to stop the exact pending effect using an existing standard without additional state binding. Such evidence would help narrow, merge, or correct the proposal.¶

41. IANA Considerations

This document has no IANA actions.¶

42. Conclusion

Revocation should not be viewed only as invalidation of a token stored somewhere upstream. For a consequence-bearing operation, the stronger question is whether a revocation that becomes authoritative before protected commit is guaranteed to control the actual effect.¶

        VALID AT ISSUANCE
               !=
        AUTHORIZED AT EFFECTUATION

        Revocation committed before protected effect
               =>
        exact pending act must re-establish authority or remain non-effective.

The model is deliberately complementary to OAuth revocation and introspection, continuous access evaluation, workload identity, attestation, policy engines, and confidential computing. Its purpose is to make the final revocation-to-effect relationship explicit, testable, and suitable for protocol review.¶

Author's Address