]> Independent Researcher

San Francisco CA US deonte@goodshyt.fun https://orcid.org/0009-0005-8586-3650

Security Web Authorization Protocol agentic authorization revocation delegation OAuth workload identity Agentic systems can derive and distribute authority across delegated agents, workloads, credentials, queues, and long-running operations. Existing revocation mechanisms can invalidate a credential or authorization grant, but credential invalidation alone does not establish that every path from revoked authority to a consequential effect has been closed. This document defines a protocol-neutral model for revocation closure. It introduces authority graphs, consequential sinks, revocation cut sets, closure states, closure budgets, and closure receipts. The model is intended to complement OAuth 2.0, workload identity, transaction-token, and agent-authorization work. It does not define a new authorization protocol, token format, or AI safety mechanism.

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. defines OAuth 2.0 token revocation and permits invalidation of a token and, where applicable, related tokens or grants. explores agent-level cascade revocation. 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:

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.

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 when, and only when, they appear in all capitals, as shown here.

Non-Goals This document does not attempt to infer model intent, deception, cognition, or semantic state. It does not specify physical shutdown mechanisms, require a particular identity system, define a new OAuth grant type, or claim closure outside the system boundary declared by an implementation.

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.

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.

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.

Example Authority Graph 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.

Dynamic Graphs Agentic systems can create new delegates and authority edges dynamically. Once invalidation begins, an implementation MUST prevent the revoked authority epoch from creating new authority-bearing edges that bypass the cut set. If the system cannot establish this property, closure status MUST be UNKNOWN, PARTIAL, or FAILED, but not CLOSED.

Closure Budget A deployment MAY define a closure budget Delta measured from acceptance of a revocation request to completed closure. If such a budget is advertised, the implementation MUST distinguish request time from completed-closure time. Cross-system timestamps MUST NOT be compared as if they share a trusted clock unless the deployment has established the required clock properties. Implementations can instead use local monotonic measurements, signed sequencing, or protocol-specific ordering.

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.

Necessary Conditions for a Scoped Closure Claim

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.

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.

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:

Illustrative Closure Receipt

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.

Mapping to OAuth and Workload Identity This section explains how the closure model relates to existing IETF mechanisms. It does not update those mechanisms.

• 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.
• 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.
• 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.
• propagates identity, authorization, and request context through a call chain. Transaction-scoped enforcement points can form part of a revocation cut set.
• provides workload-identity architecture useful for identifying enforcement subjects and workloads participating in a closure domain.
• 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.
• 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 .

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.

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.

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.

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.

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.

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.

IANA Considerations This document has no IANA actions.

References Normative References Informative References

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.

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.