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

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

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

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.