Revocation Closure for Agentic Authorization Systems

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 14 April 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

Authorization systems usually answer whether an action is permitted at a point in time. Agentic systems add a second problem: authority can be delegated, transformed, cached, queued, or propagated across multiple workloads before a revocation request arrives. In such systems, revoking one token or one principal may be necessary without being sufficient to stop consequential activity.¶

[RFC7009] defines OAuth 2.0 token revocation and permits invalidation of a token and, where applicable, related tokens or grants. [I-D.chen-oauth-agent-revocation] explores agent-level cascade revocation. [I-D.klrc-aiagent-auth] describes the use of OAuth and workload identity for agent authentication and authorization. This document addresses a narrower semantic question: when may an implementation claim that revocation is complete?¶

The core distinction is:¶

   revocation request  !=  authorization invalidation  !=  revocation closure

A revocation request is an instruction. Authorization invalidation is a state change affecting one or more grants, tokens, or policy decisions. Revocation closure is the stronger condition that, within a declared enforcement scope, no remaining authority path can produce a new consequential effect on behalf of the revoked authority epoch.¶

2. Terminology

Authority Epoch:

A bounded lifetime of authority rooted in one authorization event or independently reauthorized continuation. A new authorization after closure creates a new authority epoch.¶

Authority Graph:

A directed graph whose edges represent capabilities or authorization-bearing transitions that can contribute to a consequential effect.¶

Authorization Invalidation:

A state transition after which a previously valid authorization artifact, grant, policy decision, or derived authority MUST NOT authorize new actions within its defined scope.¶

Consequential Sink:

A resource or operation whose successful invocation creates an externally relevant effect, including network transmission, persistent state change, credential use, queue execution, financial or resource commitment, or actuator invocation.¶

Derived Authority:

Authority obtained from, delegated by, exchanged from, or otherwise causally dependent on another authorization artifact or authority epoch.¶

Pending Effect:

An operation authorized before invalidation but not yet irreversibly committed, such as queued work, delayed execution, or an asynchronous side effect.¶

Revocation Cut Set:

A set of independently enforceable authority edges such that every declared path from the revoked authority root to every in-scope consequential sink crosses at least one edge in the set.¶

Revocation Closure:

The condition in which all required cut-set edges have been enforced and no unresolved declared path remains by which the revoked authority epoch can authorize a new consequential effect.¶

Closure Receipt:

An integrity-protected statement describing the scope, status, evidence, and limitations of a revocation-closure determination.¶

3. Design Principles

1. Revocation request is not closure. An accepted request MUST NOT by itself be represented as completed closure.¶
2. Credential invalidation is not consequence reversal. Effects already irreversibly committed before closure may remain.¶
3. Derived authority is in scope unless independently reauthorized. An implementation claiming closure MUST account for derived credentials, delegated agents, transaction context, queues, and other authority-bearing descendants identified by its declared model.¶
4. Unknown is not closed. Missing evidence or unresolved authority paths MUST NOT be silently treated as successful closure.¶
5. Closure is bounded by declared coverage. A closure claim MUST identify the enforcement scope to which it applies and MUST NOT imply closure of unknown or out-of-scope systems.¶
6. Fresh authorization creates a new epoch. A closure receipt for one authority epoch MUST NOT be reused as evidence that a later, independently authorized epoch is closed.¶

4. Authority Graph and Closure Condition

Let G = (V,E) be a directed authority graph. Let C be the root of the authority epoch being revoked, and let Q be the set of consequential sinks in the declared enforcement scope. Each directed path from C to a member of Q represents a modeled way in which that authority epoch can contribute to a new consequential effect.¶

A revocation cut set K is valid only if every declared C-to-Q path intersects K. Revocation closure is achieved only after the enforcement point associated with every required member of K is active and no unresolved C-to-Q path remains.¶

                     +--> delegated agent --[e2]--> API sink
                    /
   authority root -+----> derived token ----[e4]--> storage sink
                    \
                     +--> work queue -------[e6]--> job sink

   Example revocation cut set K = { e2, e4, e6 }

   Closure requires each declared root-to-sink path to cross an
   enforced cut edge. Revoking only the root credential is insufficient
   if derived authority or already-authorized queued work can still act.

This model does not require implementations to expose their complete internal graph on the wire. Implementations MAY use internal topology, dependency indexes, grant lineage, transaction lineage, or equivalent mechanisms. However, an implementation claiming closure MUST have a deterministic method for establishing that the declared closure condition has been satisfied.¶

5. Declared Scope and Assurance Boundary

The closure condition is always relative to an identified authority epoch, a declared set of consequential sinks, and a stated observation and enforcement boundary. A receiver MUST NOT infer global or transitive coverage from a receipt that names only a local service or partial dependency graph.¶

An implementation asserting CLOSED MUST establish that its declared sink inventory and authority-lineage coverage are sufficient for the claim, or identify unresolved dependencies rather than silently assuming their absence. A path that is unknown because telemetry or delegation records are missing is not a verified cut path.¶

Evidence of a successful revocation request, a successful token-revocation response, or successful delivery of a notification is not by itself evidence that every downstream enforcement point has stopped accepting the revoked authority epoch.¶

   CLOSED(epoch, scope) requires:
     known and bounded authority-to-sink coverage;
     verified enforcement on every modeled path;
     handling of in-flight and queued effects;
     protection against new bypassing descendants;
     evidence bound to this epoch and scope.

   UNKNOWN coverage != CLOSED.

The graph cut-set formulation is a model of the closure obligation, not evidence that a particular implementation has discovered all relevant paths. Independent enforcement or observation at consequential sinks can provide stronger assurance than an agent's self-reported status.¶

6. Closure State Model

Implementations that expose closure status SHOULD use semantics equivalent to the following states, even if a protocol uses different labels:¶

REQUESTED:

A revocation request has been accepted. No closure claim is made.¶

PROPAGATING:

Invalidation is being enforced across one or more authority paths.¶

CLOSED:

All required cut-set enforcement has completed for the declared scope and no unresolved modeled path remains.¶

PARTIAL:

Some paths have been closed, but one or more known paths remain unresolved.¶

FAILED:

Required enforcement could not be completed or a declared closure budget was exceeded.¶

UNKNOWN:

Available evidence is insufficient to determine closure.¶

PARTIAL, FAILED, and UNKNOWN MUST NOT be interpreted as CLOSED. A relying component that requires closure before continuing a sensitive transition SHOULD fail closed when presented with one of those states.¶

7. Closure Receipt Model

A Closure Receipt is a protocol-neutral evidence object. This document does not define its encoding. A future profile could encode it as a signed JWT, a COSE object, an OAuth response object, a transaction-token claim, or another protocol-native structure.¶

A closure receipt SHOULD carry sufficient information to answer five questions: what authority epoch was affected, what scope was evaluated, what status was reached, when the status was reached, and what evidence or limitations bound the claim.¶

The following is a non-normative JSON example:¶

<CODE BEGINS>
{
  "version": 1,
  "closure_id": "urn:uuid:3cf0f843-64ef-4ef9-96e3-91bb9542d6f6",
  "authority_epoch": "urn:example:epoch:7f42",
  "authority_root": "sha256:7b7f...",
  "status": "closed",
  "requested_at": "2026-09-12T18:00:00Z",
  "closed_at": "2026-09-12T18:00:00.184Z",
  "coverage": {
    "sink_classes": ["api", "credential", "queue", "storage"],
    "policy_id": "urn:example:policy:agent-revoke-v3"
  },
  "cut_set_digest": "sha256:50d1...",
  "evidence_digest": "sha256:ad27...",
  "unresolved_paths": []
}

<CODE ENDS>

When a receipt crosses a trust boundary, its integrity and issuer authenticity MUST be protected by the enclosing protocol. A receipt MUST NOT contain bearer secrets or reusable credentials. Implementations SHOULD minimize topology and identity disclosure, using opaque identifiers or digests where detailed graph disclosure is unnecessary.¶

8. Mapping to OAuth and Workload Identity

This section explains how the closure model relates to existing IETF mechanisms. It does not update those mechanisms.¶

• [RFC7009] can initiate invalidation of OAuth tokens and grants. A successful revocation response does not, by itself, demonstrate that every derived authorization path, queued effect, or independently cached decision has reached closure.¶
• [RFC8693] enables security-token exchange. Where exchanged tokens derive authority from a revoked root, deployments claiming closure need a deterministic policy for invalidating or otherwise cutting those derived paths unless they have been independently reauthorized.¶
• [RFC9396] provides structured authorization details. Such details can help identify the scope or purpose whose authority is being closed, but do not themselves provide closure semantics.¶
• [I-D.ietf-oauth-transaction-tokens] propagates identity, authorization, and request context through a call chain. Transaction-scoped enforcement points can form part of a revocation cut set.¶
• [I-D.ietf-wimse-arch] provides workload-identity architecture useful for identifying enforcement subjects and workloads participating in a closure domain.¶
• [I-D.chen-oauth-agent-revocation] defines explicit agent-level and cascade-revocation mechanisms. The closure model in this document is complementary: it specifies the semantic condition under which a deployment can state that propagation has actually completed.¶
• [I-D.liu-oauth-authorization-evidence] addresses authorization evidence associated with consent and access tokens. A Closure Receipt concerns evidence produced after invalidation and should not be confused with evidence that authority was valid when originally granted.¶

OAuth deployments implementing this model SHOULD follow the security guidance in [RFC9700].¶

9. Worked Example: Delegation plus Queued Work

A user authorizes Agent A. Agent A obtains authority for Service B and submits a delayed operation to Queue Q. Service B also obtains a derived credential for Resource Server R.¶

At time t0, the user revokes Agent A. Invalidating A's access token is not sufficient for closure if the derived credential remains valid or if Q can execute the already-authorized delayed operation after t0.¶

One valid cut set for this deployment might include: (1) a gate preventing use of the derived credential at R, and (2) a gate that cancels or blocks the queued operation before the job sink commits an external effect. Only after both enforcement points report success may the deployment produce CLOSED for the declared scope.¶

If Q is outside the deployment's enforcement domain, the receipt can report PARTIAL or identify Q as out of scope. It MUST NOT represent global closure.¶

10. Operational Considerations

Implementations need not continuously materialize a full graph. A practical system can derive closure from grant lineage, token-exchange lineage, transaction identifiers, workload identities, queue ownership, policy dependencies, and sink-specific enforcement acknowledgements.¶

When closure claims are consumed across trust boundaries, the relying party SHOULD verify issuer authorization, authority-epoch binding, declared sink scope, receipt freshness, and the meaning of unresolved paths before acting on a status of CLOSED.¶

Closure computation SHOULD be idempotent. Repeated processing of the same revocation event SHOULD converge on the same or a stricter result for a given authority epoch. A component MUST NOT downgrade a known unresolved path into a closed result merely because evidence becomes unavailable.¶

Because revocation can create large fan-out, implementations SHOULD defend closure mechanisms against denial-of-service amplification. Rate limits, bounded delegation depth, batched enforcement, and asynchronous status can be used where appropriate, provided they do not cause PROPAGATING or PARTIAL states to be misrepresented as CLOSED.¶

11. Pending Operations and Commit-Time Races

Revocation races arise when an operation is authorized before invalidation but commits after invalidation or after a reported closure. Systems need a documented ordering or fencing rule identifying whether an effect belongs to the revoked authority epoch and at which point it becomes irreversible.¶

For sinks inside its declared enforcement scope, an implementation claiming CLOSED MUST account for work already admitted to queues, batch executors, retry systems, timers, and other delayed execution paths if they can create new effects after closure. A cancellation request alone is insufficient unless the relevant sink prevents the subsequent commit or the pending work is otherwise conclusively discharged.¶

In a system that allows execution to start before invalidation and finish afterward, the scope definition MUST state what is meant by a new consequential effect. Closure is not retroactive and does not reverse effects already irrevocably committed. It also must not be represented as having stopped independently reauthorized operations belonging to a new authority epoch.¶

Monotonic logical sequence numbers, authoritative sink-side commit records, epoch-aware execution checks, and independent enforcement acknowledgements are possible techniques. This document does not require a specific clock, database, queue, or consensus algorithm.¶

12. Illustrative Conformance and Falsification Cases

This section supplies non-normative tests of the semantics defined here. They are constructed cases, not measured outcomes or claims of deployment performance.¶

1. Root credential revoked; an independently cached descendant still commits to an in-scope sink. A claim of CLOSED preceding that commit fails the declared closure condition.¶
2. Root and delegated credentials revoked; a queued operation authorized earlier executes after the claimed closure boundary. If the new commit remains attributable to the revoked epoch and is within scope, the closure claim fails.¶
3. A known external queue lacks a trustworthy enforcement acknowledgement. The implementation reports PARTIAL or UNKNOWN, not CLOSED.¶
4. A replayed receipt names a different authority epoch or stale scope. A relying party rejects the receipt as inapplicable.¶
5. Independently reauthorized work commits after the old epoch is closed. Its effect is recorded against the new epoch rather than attributed to a failure to close the old one.¶
6. An effect irrevocably committed before the closure boundary remains visible afterward. This alone does not disprove closure, which concerns new effects.¶

An independent observer can challenge a closure receipt by finding an in-scope post-closure effect that derives from the revoked epoch. An implementation SHOULD retain enough authenticated evidence to investigate such a counterexample without disclosing unrelated identity or topology information.¶

13. Privacy Considerations

Authority graphs can reveal organizational structure, user relationships, delegation topology, resource names, and sensitive operational context. Closure receipts SHOULD disclose only the minimum information necessary for the relying party to evaluate the closure claim.¶

Opaque authority-epoch identifiers, hashed cut-set descriptions, scoped evidence digests, and selective disclosure can reduce unnecessary topology exposure. Closure evidence SHOULD NOT become a durable global correlation identifier for a user or agent across unrelated authorization contexts.¶

14. Security Considerations

A forged CLOSED result is security-critical because it can cause a relying party to proceed under the false assumption that revoked authority can no longer create consequences. Closure receipts crossing trust boundaries MUST therefore be integrity protected and authenticated.¶

Receipts are vulnerable to replay if not bound to an authority epoch, scope, and freshness context. A relying party MUST reject a receipt that does not correspond to the authority epoch being evaluated.¶

An incomplete authority graph creates false closure. Implementations MUST treat known-but-unobservable dependencies conservatively. Unknown external systems, offline actors, cached credentials, pending asynchronous operations, and independently authorized descendants MUST be represented as limitations, unresolved paths, or separate authority epochs as appropriate.¶

Revocation is inherently subject to races. A consequential effect may commit while revocation is propagating. Implementations MUST NOT claim that closure reverses effects that became irreversible before closure.¶

Closure evidence itself can become a sensitive security artifact. Evidence stores SHOULD be access controlled and SHOULD provide tamper evidence suitable for the deployment's threat model.¶

15. IANA Considerations

This document has no IANA actions.¶

Appendix A. Changes Since Version -00

This section is informational and intended to assist reviewers; it may be removed from a future RFC. Revision -01 clarifies the limits of declared coverage, the difference between graph modeling and verified enforcement, in-flight and queued work around the commit boundary, and six illustrative tests of closure semantics. It retains the protocol-neutral Informational scope and defines no new token, API, or IANA registry.¶

Appendix B. Open Questions for Further Work

Future protocol work could determine whether closure receipts require a common encoding, how closure status should be discovered across trust domains, how graph coverage can be proven without disclosing sensitive topology, and how closure evidence should bind to protocol-specific authorization epochs.¶

Author's Address