OAuth 2.0 Bounded Work Authorization

Introduction

Problem Statement OAuth 2.0 provides mechanisms for requesting and granting access to protected resources, constraining the access tokens issued for that access, and managing their lifecycle. Tokens can be revoked , their state can be queried , and Rich Authorization Requests carry structured permissions through consent to Resource Server enforcement. A deployment can use these mechanisms to govern work a user approved. OAuth does not, however, define a common contract that identifies the approved work and associates its bounds and termination with the credentials issued for it. As a result, independently implemented clients, Authorization Servers, and Resource Servers cannot infer from existing OAuth mechanisms alone which credentials belong to the same approved work, which approved bounds govern them, or what ending that work requires of subsequent issuance and resource access. A simple question shows the gap: if the agent's identity is valid and its access token is valid, can an individual operation still be impermissible because the work it belongs to has ended? This document argues that it can. Today the answer depends on the policy of a particular Authorization Server, which no other party has a protocol means to discover or rely on. The same gap appears as four questions about any approved piece of work. Each is asked by a second party: someone other than the Authorization Server that issued the work's credentials. Question Who asks What answers it today What was approved, by whom, and what were they shown? Auditor, subject, incident responder The issuing Authorization Server's private consent records; authorization details are returned per token, not per approval Is it still approved now? Resource Server, second Authorization Server, policy decision point Token-level state only: introspection and token status describe a credential, not the work it serves Which credentials and actors belong to it? Auditor, security tool Nothing joins them: an actor chain describes one token, and a grant identifier, where one exists, is returned only to the client How is this one piece of work stopped without stopping the client's other work? Approver, administrator, security tool Revocation keyed by a token and limited to the client that holds it, a client-only grant management API, or disabling the client Deployments approximate answers with short token lifetimes and custom Authorization Server logic, and the outcome depends on those implementation choices. This document describes a framework for those relationships. Its purpose is to establish common semantics for approved bounded work while composing with existing OAuth authorization, token, and lifecycle mechanisms.

Why Now Approval and use have come apart. A consent screen works when a person approves access and the client uses it at the same time, at one Authorization Server. In agent deployments, a person approves a piece of work once and an agent carries it out later, over hours and process restarts, in many tokens obtained by code exchange, refresh, and token exchange, through sub-agents, and with authority that has to change while the work runs. Authority is also growing while explicit approval thins. Under the Model Context Protocol's authorization specification, a client that meets a scope challenge requests "the union of the client's previously requested scope set and the scopes from the current challenge" . Its enterprise-managed authorization extension makes the organization's identity provider "the authoritative decision-maker", which issues tokens through an identity assertion grant "without additional per-server authorization prompts" . Each choice is sound on its own. Together they move more authority through fewer approvals, with nothing tying that authority to the work it was approved for. Containment is coarse. In August 2025, compromised OAuth tokens associated with the Salesloft Drift application were used against Salesforce customer instances; containment revoked all of the application's access and refresh tokens and removed the application from the Salesforce AppExchange . Incidents establish urgency, not requirements. Related specifications already presume an object for the work. Delegated refresh tokens require a client to "promptly revoke the refresh-token family when that task reaches a terminal state" . WIMSE AIMS expects the translation of a mission into authorization requirements "to occur as a planning step before the Agent requests authorization" and places it out of scope (Section 10.1 of ). An agent authorization gap analysis says a user "should be able to revoke authority associated with a specific task without affecting unrelated tasks performed by the same agent" . None of them defines what that task is to an Authorization Server.

Approach and Scope This document proposes that OAuth authorization for delegated work be based on approved bounded work. Its core is the three invariants of : approval of a specific piece of work, through a trusted decision, sets the ceiling on the agent's authority; every credential derived under it stays within that ceiling and remains associated with it; and approval evidence never substitutes for current authority. Ending the work has defined consequences for issuance and resource access within a stated acceptance window (, ). The framework rests on three objects: A bounded work proposal: requested work with an identity, bounds, and termination conditions. The governing authorization: the durable authorization record that an approval decision establishes for the proposal, with a lifecycle. Approval evidence: a durable record of the authorization decision and the approved bounds. This revision seeks agreement on three questions: whether OAuth should standardize the association between approved work and the authority issued for it; which approval, authority-containment, and termination behaviors form the common core; and how existing mechanisms and proposals can realize that core. Wire representations and optional capabilities will follow that agreement. For the same reason, this revision uses no BCP 14 requirement keywords: its statements describe the semantics a realization provides, and normative requirements will follow once the working group agrees on them. Shaping the details is an invitation to the working group and to collaborating authors. This revision covers work that reaches more than one Authorization Server, as when an agent obtains a token for the same work at a second Authorization Server through an identity assertion grant . Each Authorization Server decides under its own policy and the trust that identity chaining already establishes; a second Authorization Server honors the governing authorization's bounds without widening them, and refuses what it does not recognize.

Terminology This document uses the terms "access token", "authorization server", "client", "refresh token", "resource owner", "resource server", and "scope" defined in , and the following terms.

Bounded work proposal:: A description of requested work, including the proposed resource and action bounds and the conditions under which the work's authorization should end. A proposal is input to an authorization decision and confers no authority.
Governing authorization:: The durable authorization record established for approved work. It identifies the work, records the approved bounds and termination conditions, and maintains the authorization's current lifecycle state. Credentials issued under it are associated with it and cannot confer authority beyond its approved bounds.
Approval record:: The part of a governing authorization that records what was approved: the work as described, the approved bounds, the termination conditions, and the accountable approver. It is fixed at approval and does not change, including when the authorization ends ().
Approval evidence:: An integrity-protected record of a particular authorization decision and the approved bounds to which that decision applies, bound to the decision rather than to any token ().
Association:: The link between a credential and the governing authorization it was issued under, carried in the credential or held by the Authorization Server, that lets a second party relate the credential to the work (). An actor chain does not by itself carry it.
Resource enforcement:: The Resource Server's evaluation of each requested operation against the governing authorization: both its lifecycle and its bounds. It is distinct from evaluating each action at a separate policy decision point, which this revision does not define.
Second party:: Any party other than the Authorization Server that issued a credential, such as a Resource Server, a policy decision point, an auditor, or an administrator's security tool.
Issuance path:: Any token endpoint operation that yields a credential, including authorization code exchange, refresh, token exchange, and redemption of an assertion grant .
Agent:: An OAuth client that pursues delegated work on a user's behalf with substantial autonomy in how it sequences individual operations.
Approver:: The party whose authorization decision establishes a governing authorization, recorded on it as the single party accountable for the decision (). The decision may be standing: an approval of a class of work that policy activates one instance at a time.
Subject:: The user on whose behalf the work is performed. The subject and the approver are often the same person but need not be; for example, a manager can approve work performed on an employee's behalf.
Realization:: A specification or deployment that provides the semantics of this framework through concrete protocol mechanisms, including how the association is carried, where lifecycle information comes from, and its acceptance window ().

Use Case: Approved Bounded Work This section walks through the scenario the framework is designed for, in sequence. The scenario is simple: no unusual trust relationships, no cross-organizational mechanisms, one user, one agent, one Authorization Server, and two Resource Servers. The user, Alice, is both the subject of the work and its approver. summarizes the sequence; the subsections that follow walk through it in order.

| | | | | (1) bounded work proposal | | |------------------------------->| | (2) disclosure: work, bounds, end | |<-----------------------------------------| | (3) approval | | |----------------------------------------->| | | | | (4) governing | | | | authorization | | | | active; approval | | | | evidence recorded | | (5) access token | | |<-------------------------------| | | (6) CRM read | | 20:00 | |-------------->| | | | | (7) introspect | | | |--------------->| | | | active | | | |<---------------| | | allowed | | | |<--------------| | | (8) withdraw | | 22:00 |----------------------------------------->| | | | | (9) ended; | | | | issuance refused | | (10) risk read| | 23:00 | |-------------->| | | | | (11) introspect| | | |--------------->| | | | inactive | | | |<---------------| | | (12) denied | | | |<--------------| | | | | | ]]>

A Bounded Work Proposal Alice asks her personal agent: "analyze the Q3 sales pipeline and file a report." The agent formulates a bounded work proposal and submits it to the Authorization Server:

The Authorization Server discloses the proposal to Alice before anything is approved. What Alice sees is a piece of work, not a list of API scopes: what will be done, what it may touch (the bounds that will be enforced), when it will be finished, and the latest time its authority lasts. In this example the agent reports completion once the report is filed (). Here the unit of authorization is the work. In conventional OAuth the unit is the request, or at best a standing permission of the client. The work has an identity of its own, and everything that follows (the approval, the evidence, the tokens, the withdrawal) attaches to that identity, not to individual requests. Alice's intent informs the proposal; the proposal is what she is able to approve. Intent, however expressed, never directly creates authority ().

Approval Alice approves the proposal at the Authorization Server, which authenticates her and verifies that the bounds are hers to approve. The agent neither presents the disclosure nor relays the approval. Her approval establishes two distinct things, and keeping them distinct is central to the framework. First, the Authorization Server creates a governing authorization for this work: the authority under which the agent will act, with the bounds Alice saw and the termination conditions she agreed to. Second, the Authorization Server creates approval evidence (): a durable record of what was decided and what was approved (the work, its bounds, its end), kept for accountability after the work is over. The evidence is not the authorization: it establishes why the authority exists, not what the authority currently permits ().

Working Within Bounds At 20:00 the agent begins. Each access token it obtains is associated with the governing authorization. In this example, both Resource Servers introspect each presented token , and the Authorization Server incorporates the governing authorization's lifecycle state into the result. When the token is presented at a Resource Server, the operative question is not merely "is this token valid?" It is: Is the governing authorization for this operation still active, and is this operation within its bounds? The question has two parts; each fails independently. The lifecycle part (is the authorization still active?) fails for a valid token whose work has ended. The bounds part (is this operation within its bounds?) fails for a valid token on live work that reaches outside what was approved. In this scenario, reading Q3 opportunities and Q3 risk assessments succeeds, and so does creating the "Q3 pipeline" report. Modifying a pipeline record, creating a report under any other name, or reading payroll is out of bounds no matter how valid the token is. The bounds part of the question also has a granularity that matters. Bounds may be class-scoped ("read access to the CRM system") or instance-bound ("this report", "this payment, to this payee"). A bound that names the specific objects of the approved work cannot be satisfied by substituting a different object of the same class: a payment bound to one payee is not authorized by a general authority to make payments. Which granularity a proposal's bounds use is a decision of the proposal itself, and the framework permits both. Bounds that name specific objects leave less room between what the bounds permit and what the work needs ().

Delegating Part of the Work At 21:00 the agent hands the risk-system reads to a sub-agent (not shown in ). It exchanges its access token for one issued to the sub-agent . The Authorization Server issues the new token only because the governing authorization is active, limits it to the reads in the risk system, and associates it with the same governing authorization. The new token's actor chain names the agent and the sub-agent, but the association, not the actor chain, is what ties it to Alice's approval (). Without that association, the exchange would produce a credential that no longer depends on the work: a token exchange "does not create a tight linkage between the input and output tokens" (Section 2.1 of ). With it, when Alice withdraws the work at 22:00, the sub-agent's next request is denied in the same way as the agent's ().

Withdrawal At 22:00, Alice withdraws the work at the Authorization Server. She withdraws the work itself: not a token, not a session, not a client registration, and without the agent's cooperation. Because the work is represented by a governing authorization, withdrawal is a state change to that single object. The Authorization Server records the authorization as ended and refuses further token issuance or refresh under it, and its next introspection response for any token associated with it reports the token inactive. Other independently approved work performed by the same agent remains governed by its own authorizations and is unaffected. The approval evidence does not disappear, and it does not change: it still records what Alice approved and when. The withdrawal, and when it happened, is recorded separately and linked to the governing authorization. Ending the authority and keeping the record do not conflict; they are different objects, which is why the framework separates them.

Further Protected Operations Are Denied At 23:00, the agent attempts its next operation. The token it presents is structurally valid; the client authentication succeeds; the token has not expired. The Resource Server's lifecycle check nonetheless fails: the governing authorization has ended. The operation is denied. The agent cannot continue the task because the access it requires is denied; what it completed before 22:00 remains completed. The timing of this denial depends on how the realization delivers lifecycle information. Because the Resource Servers in this example introspect every token, the denial follows the withdrawal at the next request. A realization that relies only on short token lifetimes denies the same request once the token issued before 22:00 expires, which can be later than 23:00; it still conforms, because its acceptance window is that lifetime (). The framework does not make an ending take effect faster: with token lifetimes alone, a credential already issued stays accepted until it expires, as it does today after a refresh token is revoked. What it changes is who can end one piece of work (the approver or an administrator, not only the client that holds its tokens) and which participants honor that ending: Resource Servers, delegated credentials, and a second Authorization Server. This is the outcome the framework aims to make predictable across implementations (): a valid credential does not authorize further operations for work that has ended, within an acceptance window the realization states.

Further Use Cases The walkthrough above is one case. The following cases are equally ordinary, need no new trust model, and stress other parts of the same gap.

Standing approval:: An administrator approves a class of work once, and policy activates each run with no consent screen. Each run still needs its own record of what it was allowed and who is accountable for it, and each has to be stoppable on its own.
Work that outgrows its approval:: An agent approved to post adjustments under $500 meets one that needs $600. The request is refused, and asking for more produces a new approval that the approver sees as such, not a silent widening of the existing one.
Stopping one piece of work during an incident:: A security tool that holds none of the work's credentials detects misuse. It needs to stop that work within a stated time, while the same client's other work continues.
Audit after the fact:: Months later, an auditor reconstructs what was approved, what the approver was shown, and which credentials served the work.
Work across two Authorization Servers:: An agent reconciling invoices in an enterprise system, protected by the enterprise's Authorization Server, also opens tickets at a partner's service that has its own Authorization Server, reached through an identity assertion grant. When the approver withdraws the work, neither Authorization Server issues anything more for it, and credentials already issued stop being accepted at both within a stated time.

Existing Mechanisms and the Missing Contract Each existing mechanism contributes to the use case. None of them defines how the approved work relates to the credentials, bounds, and termination involved: Mechanism Existing capability Additional bounded-work semantics Grants and access tokens Represent the resource owner's authorization and support issuing credentials with constrained authority A common association with identified approved work Scope AS-defined permission strings associated with requested and granted access Structured, work-specific bounds and their interpretation Token revocation Lets a client revoke a token it holds; revoking a refresh token should also invalidate access tokens from the same grant where the Authorization Server supports it, and other cascades depend on its policy Required consequences of ending an identified work authorization, independent of token possession Token introspection Reports whether a token is currently active, including whether it has been revoked, and supplies authorization information A defined relationship between ending the work and token activity Rich Authorization Requests Structured permissions carried through consent to Resource Server enforcement Work identity, lifecycle, and associated approval evidence Token exchange Issues a new token, for example to a sub-agent, based on an existing one, without a lasting link between them Delegated credentials that stay associated with the same approved work and end with it Grant Management Identifiable, queryable, and revocable concurrent grants, managed by the client The properties listed below The closest composition of these mechanisms uses a pushed authorization request with authorization details for the approval, resource indicators to narrow each token, Grant Management for one grant per piece of work, token exchange for sub-agents, and the Continuous Access Evaluation Profile to tell Resource Servers of a revocation. It approximates the use case for the client at one Authorization Server, and it breaks wherever another party has to rely on it. Several properties remain undefined: Association visible to Resource Servers. Grant Management identifies a grant only between client and Authorization Server, and leaves how grant data reaches a Resource Server to the deployment. A Resource Server has no common way to tell which approved work a token belongs to. Consequences of ending. Revoking a grant revokes its refresh tokens, but revoking its access tokens is recommended rather than required. Token revocation likewise recommends, but does not require, invalidating access tokens when their refresh token is revoked, and leaves other cascades to Authorization Server policy. Token expiry bounds how long a Resource Server continues to accept a token, but nothing ties that bound to the ending of the work the token was issued for, or makes it known to the parties that rely on it. Withdrawal by the approver. Token revocation and Grant Management are client-facing. Neither defines how the approver, or an administrator, ends an identified authorization independent of the agent and of possession of any token. Termination conditions. No mechanism defines a criterion under which the work is complete, or distinguishes completion from withdrawal, administrative termination, or expiry. Stable approvals. Grant Management can merge into or replace an existing grant. In this framework the approval record does not change; broader authority requires a new authorization decision. Evidence of the approved bounds. No standardized mechanism records, in a verifiable form, the decision together with the enforceable bounds it approved. Delegation. A token obtained by exchange is not tightly linked to the token it was exchanged for, and propagating revocation between them "is not a general property" of token exchange (Section 2.1 of ). Ending approved work therefore does not reach a sub-agent's credentials unless both are associated with the same work. Discretionary narrowing. The resources a token may target are at the Authorization Server's "sole discretion", and a refresh token returned alongside a narrower access token "is bound to the full original grant" (Section 2.2 of ). For authorization details, "there is no standardized mechanism to compare two arbitrary authorization detail requests" (Section 6.1 of ). A credential derived later can therefore be as broad as the original grant. Accumulating consent. Grant Management's merge action combines newly consented permissions "with those which already exist within the grant", and Rich Authorization Requests expects deployments to "merge requested and preexisting authorization details" (Section 11.2 of ). Approvals given at different times for different work can fold into one grant that no one approved as a whole. Cross-domain issuance ignores approval state. An identity provider issuing an identity assertion grant "evaluates administrator-defined policy" (), not whether the work the grant serves is still approved, so ending the work at one Authorization Server does not stop issuance at another. Most of these gaps admit a point fix, and each fix presumes the same three properties: one authorization per approved piece of work that is never merged into or replaced; a check of it on every issuance path; and an association with it in every credential issued for the work. Adopted separately, point fixes key to different things (a token, a refresh token family, a grant identifier, an authorization details type) and together still cannot stop one piece of work everywhere. A deployment can instead coordinate them into one profile, such as one never-merged grant per piece of work with its identifier in a deployment-defined introspection member. Even then, how a Resource Server reads that identifier, how the approver or an administrator ends the grant, how delegated credentials stay with it, and whether a second Authorization Server refuses each rest on agreements private to that deployment, which the evaluation in excludes. Such a profile would be one realization of the framework in , which describes that shared presumption: an identity, bounds, and termination for the work that every participant interprets the same way, rather than a grant that only its client manages.

A Framework for Approved Bounded Work This section describes the conceptual framework at the level of objects, invariants, and obligations. It does not specify wire formats; mapping to OAuth message syntax is left to future work.

Framework Objects The three objects are conceptual roles. This framework does not yet require them to be separately serialized artifacts, or require every Resource Server to receive the complete approval record.

Bounded Work Proposal A bounded work proposal describes requested work as a unit with an identity, bounds, and termination conditions: Work: what is to be done, described in terms the approver can understand. Bounds: the resources, systems, and actions the work may use, expressed as restrictions whose semantics the Authorization Server and the enforcing Resource Servers understand. Termination conditions: when the work is done (its termination criterion), and a maximum lifetime: the latest time at which its authorization ends even if the work is never done. The description and the bounds serve different purposes. The description explains the requested work; the bounds identify the restrictions that are enforced. A description such as "analyze the Q3 pipeline" does not itself restrict anything, and it has no portable meaning: two Authorization Servers can reasonably derive different bounds from the same description. Interoperability therefore begins at the approved bounds, not at the description. The bounds in a proposal are a request. The Authorization Server determines the bounds it discloses for approval, which can be narrower than those proposed, and the approver can narrow them further before approving. The approved bounds are the disclosed bounds as the approver left them. Where the Authorization Server shows the agent's description of the work, it shows it as the agent's, apart from the bounds. The proposal is what is disclosed to the approver and what the approval decision is about ().

Governing Authorization The governing authorization is the durable authorization record that an approval decision establishes for a proposal. It identifies the work by an identifier of its own, distinct from the client and from any credential issued under it, records the approved bounds and termination conditions, and has a lifecycle (). Credentials issued for the work are associated with it (). It is the object a Resource Server evaluates operations against, and the object that is withdrawn. Applicable policy may further restrict the authority usable under it without changing the original approval record. The governing authorization has two parts that change differently: a record of what was approved, which is immutable, and a state, which changes over the lifecycle. The approval record remains unchanged when the governing authorization ends. The record in turn identifies the work and holds the approved bounds. A realization can carry the bounds as structured authority, such as authorization details , separately from the work's identity, provided the two remain associated. The approval record is what the Authorization Server enforces against; approval evidence () is its verifiable form for parties that do not rely on the Authorization Server's own records.

Approval Evidence Approval evidence is a durable record of the authorization decision and the approved bounds: the verifiable form of the governing authorization's approval record. In this revision it is signed by the Authorization Server and bound to the decision, not to any token. It outlives both tokens and the work itself, and it does not change. Lifecycle transitions and execution information are retained in separate records linked to the governing authorization and, where relevant, to the approval decision; adding to that history does not modify the original evidence. A signature made at approval time attests to the decision, not to what happened afterward. Approval evidence serves parties that need to verify what was approved without relying on the Authorization Server's live records: the approver and auditors after the fact, a party resolving a dispute, or a Resource Server that a realization requires to check proof of approval before a high-consequence operation. No party needs it to decide whether an operation is permitted now (). Where no party outside the Authorization Server verifies approvals, a realization can keep the approval record without producing separate evidence.

Invariants Three invariants govern the relationships among the three objects. Each prevents a specific failure. Trusted approval establishes the authority ceiling. Neither the subject's intent nor a proposal, however detailed, confers authority. The Authorization Server establishes a governing authorization only after obtaining an authorization decision through a trusted approval mechanism. The decision is bound to the disclosed work and its enforceable bounds. The Authorization Server verifies the approving party's authority and applies its policy; the resulting authorization cannot exceed the approved bounds. This prevents two failures: an agent establishing approval merely by claiming that the approver approved, and an approver granting authority they are not entitled to grant. The ceiling does not rise after approval. Any narrowing before approval, by the Authorization Server or the approver, only lowers it, and work that needs more authority requires a new authorization decision (). An approval can also be standing: an approver approves a class of work once, and policy activates each instance without a new consent screen. Each instance still has its own governing authorization, which records the approval basis it was activated under and the accountable approver, and each can be ended on its own. Activation is the authorization decision for the instance: its approved bounds are those policy selects within the standing approval's bounds, recorded with that basis. A standing approval sets a ceiling for the instances it activates; it does not let policy widen any instance beyond it. Derived authority remains bounded and associated with the work. Each credential issued under a governing authorization remains associated with it and conveys no more than the authority available under its approved bounds and the grant or credential from which it derives. A credential may carry a narrower subset, judged by a comparison defined for the type of authority; where none is defined, or it cannot decide, the Authorization Server refuses. Authorization details have no standardized comparison (), so defining comparisons for common types is work this framework leaves open. Refresh and other supported derivation operations preserve the association and the applicable restrictions. Credentials obtained by delegation, such as a token exchange that passes part of the work to a sub-agent, remain associated with the same governing authorization, carry no more authority, and end when it ends. An actor chain in such a credential records who acted through whom; it does not by itself carry the association. A credential's own restrictions still apply at the Resource Server (): a governing authorization that permits reads and writes does not turn a read-only token into a write credential. Historical approval evidence does not establish current authority. Approval evidence records the decision and the approved bounds at the time of approval. Its continued availability, or successful verification of its signature, does not establish that the governing authorization remains active, cannot substitute for the required lifecycle checks, and cannot reactivate an ended authorization. Approval evidence also shows only what was approved, not that the approved bounds were the right reading of the work. This prevents evidence from becoming a second, longer-lived credential that outlives the authority it records.

The Authorization Lifecycle A successful authorization decision establishes an active governing authorization, which later ends:

active:: Authority may be issued and exercised under the governing authorization, subject to the checks of and .
ended:: No further authority may be issued under the governing authorization, and Resource Servers apply its ending as described in . Ending is terminal.

Only active permits issuance or reliance. A realization may define further states, such as a non-terminal suspension, but any state other than active, including one a party does not recognize, permits neither. A second party authorized to do so can ask the Authorization Server whether a governing authorization is active. The subject, the approver, or an administrator can end a governing authorization at the Authorization Server, without the agent's cooperation and without possessing any token issued under it. The Authorization Server records why the authorization ended. The reason distinguishes: completed: the termination criterion has been satisfied. abandoned: the agent gave up the remaining work and the authority for it. withdrawn: the subject or the approver withdrew the work. terminated: an administrator or a governance process ended it. expired: the maximum lifetime approved for the work passed. When the Authorization Server records the ending, it refuses further issuance, refresh, and other supported derivation under that governing authorization. Where that Authorization Server also issues the identity assertions the work uses at another Authorization Server, the refusal covers new assertions; where a separate identity provider issues them, that provider learns of the ending as a second Authorization Server does. A second Authorization Server that the work reached refuses issuance for it once it learns of the ending. Until it does, it can issue only on an assertion obtained before the ending, and a token it issues on that assertion is accepted until the token expires. The acceptance window there is therefore the assertion's remaining lifetime plus the lifetime of a token issued on it, and no such token outlives the work's maximum lifetime (). Further work requires a new proposal and a new authorization decision. The same holds while a governing authorization is active: work that needs more authority than it allows requires a new decision, which establishes a new governing authorization rather than changing the existing one. The existing authorization continues under its own bounds until it ends; a realization can end it when the new one is established, and can record how the two relate. A termination criterion in a proposal does not by itself establish that the criterion has been satisfied. The deployment identifies who may report completion or abandonment and what the Authorization Server relies on. Because ending only removes authority, such a report, even from the agent itself, cannot widen access. A report the Authorization Server accepts does end the work, and ending is terminal: work that a premature report cuts short needs a new authorization decision to continue. Abandonment is a decision to give up the work, not a failure: an attempt at the work that fails, is interrupted, or is restarted does not by itself change the governing authorization's state. The agent can resume only while the authorization is active and the checks of and succeed. Under a standing approval, ending one instance leaves the standing approval in place, and policy can activate a new instance (). What needs authenticating is the source of the recorded reason, because "completed", "abandoned", and "withdrawn" mean different things after the fact. A maximum lifetime ensures that work nobody ends does not retain authority indefinitely.

Resource Enforcement At a Resource Server, the operative question for an operation under this framework has two parts: is the governing authorization for this operation still active, and is this operation within its bounds? Each part fails independently, and neither replaces the checks OAuth already requires. The bounds part checks that an operation falls within the approved bounds, not that it serves the approved work. Approved bounds are an envelope for work whose individual operations cannot be listed in advance: an operation inside them is permitted whether or not it advances the work. The gap between that envelope and what a given run actually does is where the residual risk of delegated work lies, and this framework narrows it only as far as the bounds themselves do. Bounds that name specific objects narrow it further (); other measures, such as separate approval of individual high-consequence operations or limits on cumulative use, are outside this revision. Before accepting a protected operation under this framework, a Resource Server validates the presented token under the applicable OAuth rules, including client authentication and proof of possession where they apply. It establishes the governing authorization the token is associated with, verifies that the operation satisfies both the token's restrictions and the approved bounds, and applies its own resource policy. Because the Authorization Server issues no credential broader than the approved bounds (), a Resource Server can check the bounds from a token that carries them in a form it understands, and otherwise from introspection, as it already does for an opaque token. It also establishes that the governing authorization is active under the freshness rules of the applicable realization. Failure of any required check causes denial. The conditions compose conjunctively: a valid credential for the right client never overrides an ended governing authorization, an active governing authorization never bypasses presenter authentication, and neither overrides a client or client instance that the deployment has revoked or suspended. For an operation that a Resource Server protects under this framework, it also refuses credentials that carry no association with a governing authorization; otherwise an agent holding an ordinary credential for the same resource would be unaffected when the work is withdrawn. Which operations require an association is the Resource Server's policy, and a realization makes it discoverable, for example through protected resource metadata . A realization of this framework defines an acceptance window: a finite limit on how long an operation can still be accepted after the Authorization Server records that the governing authorization has ended. It identifies the authoritative lifecycle information that enforcement points use, how long previously obtained information may be relied on, and the behavior when sufficiently fresh information is unavailable. It makes the window known to the clients and Resource Servers that rely on it, so that each can tell how long an ending can take to reach enforcement. A Resource Server refuses further operations once it learns that the governing authorization has ended, does not rely on previously obtained active-state information beyond its defined validity, and denies an operation when it cannot establish the required lifecycle condition within that window. An agent needs to tell apart the reasons an operation is denied, because each calls for a different response. When the governing authorization has ended, the agent stops the work and does not retry or seek a new credential for it. When the operation is outside the approved bounds, more authority requires a new authorization decision. When only the credential has failed, the agent can obtain a new one while the authorization remains active. Where more than one applies, an ended governing authorization takes precedence, then an operation outside the bounds. A realization conveys which of these applies, within the limits of its disclosure policy, for example in token, introspection, and resource error responses. Conveying the reason departs from two OAuth defaults. Token introspection advises against including "why the token is inactive" in a response (Section 2.2 of ), and the "invalid_token" error lets a client "request a new access token and retry" (Section 3.1 of ). For a token whose governing authorization has ended, the first leaves the client unable to tell that the work has ended, and the second sends it back to that work. A realization that conveys the reason gives it only to parties entitled to the governing authorization's state. The lifecycle information may come from per-request token introspection , another authenticated state mechanism, or a bounded token lifetime whose issuance was gated on the governing authorization being active. Where it comes from introspection, a token whose governing authorization has ended is reported inactive, so a Resource Server that already introspects applies the ending without change. State embedded in a token reflects an earlier authorization decision; it does not by itself reveal a later withdrawal. Where a bounded token lifetime is the only mechanism, the acceptance window is that lifetime. In every case, no credential issued under a governing authorization remains valid past the authorization's maximum lifetime. This framework governs authorization of protected operations at participating enforcement points. Ending a governing authorization does not by itself undo completed effects or cancel execution that another system has already accepted. A realization that governs such execution identifies the additional checkpoints and cancellation behavior it provides.

Relationship to Other Work The framework does not depend on any specific underlying mechanism: it names the objects and their obligations, and composes with existing OAuth work rather than replacing it. Existing and proposed specifications provide mechanisms relevant to it. The relationships below identify contributions to possible realizations; they do not imply that every listed specification already provides every bounded-work guarantee. Rich Authorization Requests provide structured authorization requests, consented permissions, and information for Resource Server enforcement, a natural carrier for a proposal's bounds. Grant Management provides independently identifiable, queryable, and revocable concurrent grants between a client and an Authorization Server; lists what it leaves undefined. The Mission specification provides a durable approved-work identity, commitments to the approved authority, the association of tokens with it, and lifecycle-gated issuance, with observation of lifecycle state through token introspection as an option. Mission's terminated state realizes this framework's ended authorization, and its termination reason, revoked or expired, records why; revoked covers both withdrawal and an administrative ending. Companion documents in preparation add per-entry completion conditions and a completed reason, consent evidence, and execution capabilities. In Mission's terms, the bounded work proposal is the Mission Intent and the authority proposal submitted beside it, the governing authorization is the Mission together with the Authority Set derived for it, and approval evidence is the approval event's integrity commitments. Agent Operation Authorization turns an agent-proposed operation policy into a runtime-enforceable authorization once the user confirms it. Its current revision defines no lifecycle for that authorization beyond token expiry. Authorization Evidence carries and verifies records of user confirmation in access tokens. Its signature covers the content displayed to the user, not the enforceable bounds; a mapping to this framework would bind the decision to the approved bounds as well. Domain-Specific Authorization Schemas carries a schema instance in authorization details. A requested instance is a bounded work proposal; an approved instance, identified by a work identifier, is a governing authorization with this framework's lifecycle, ending as completed, withdrawn, terminated, or expired, after which the Authorization Server refuses further issuance, refresh, and derivation. Its Resource Servers check each operation against the approved instance. It leaves approval evidence to complementary work, such as Authorization Evidence. Token introspection and token revocation are existing primitives from which resource enforcement and withdrawal can be assembled. GNAP manages a grant through its continuation API, including revoking it, and can rotate and revoke access tokens; a GNAP grant is a candidate carrier for a governing authorization. Token Status List , and the Shared Signals Framework with the Continuous Access Evaluation Profile , can deliver status changes to enforcement points before tokens expire, and so can shorten a realization's acceptance window. The identity assertion authorization grant , identity chaining across domains , and transaction tokens carry identity and authority across trust domains and call chains. None of them defines approval state for the work; an identity provider issuing an identity assertion grant "evaluates administrator-defined policy". Refresh token and authorization expiration tells a client when a refresh token expires and when the underlying authorization ends. Deferred token response lets a token request complete later, which suits an approval given while the agent waits. RAR metadata and error remediation lets a Resource Server signal insufficient authorization details, which a realization can use to report an operation outside the approved bounds (). AAuth defines missions with their own lifecycle at its Person Server, for AAuth rather than for deployed OAuth 2.0 Authorization Servers. An agent authorization use case and gap analysis identifies authorization context, delegation chain, and mass revocation gaps that overlap . The Mission specification shows that the three objects can be realized end to end, but it is one realization, with its own token claims, commitments, and authority vocabulary. Grant Management shows that grants can be identified and managed, but not the work-level semantics listed in . This framework states the semantics that any realization provides, so that the working group can decide which of them to standardize, and how existing mechanisms carry them, independently of any single realization.

Requirements and Evaluation

Requirements The framework's semantics reduce to the requirements below. Each states what a realization needs to do, not how, and each can be checked by a party that did not build the Authorization Server. # A realization needs to How a second party checks it Stated in R1 Give each governing authorization an identifier distinct from the client, any token, and any refresh token family Two pieces of work for one client and subject receive distinct identifiers R2 Fix what was approved (the bounds, the work as described, and the accountable approver) at approval; more authority creates a new governing authorization, never an edit The approval record reads the same before and after a request for more authority , R3 Issue no credential broader than the approved bounds, under a comparison defined for the type of authority, and refuse where the comparison cannot decide A token exchange asking for a $600 limit against a $500 approval is refused; one asking for $250 succeeds R4 Refuse every issuance path once the governing authorization has ended After the work ends, code exchange, refresh, and token exchange each refuse R5 Let an authorized party holding no token end one governing authorization without affecting the client's other work A security tool ends one of two pieces of work; the other continues R6 Bound the acceptance window: credentials already issued stop being accepted within a time the realization states Tokens issued before the ending stop being accepted within the stated time R7 Let a second party relate each credential to its governing authorization, from the credential or from the Authorization Server, without inference A Resource Server and an auditor each name the work from one of its tokens , R8 Let an authorized second party ask whether a governing authorization is still active A query by identifier returns the current state R9 Have a Resource Server refuse credentials that carry no association with a governing authorization, for the operations it protects under this framework, and make those operations discoverable An ordinary token for the same resource, obtained outside the work, is refused for a protected operation Where the work reaches more than one Authorization Server, R4 and R6 apply at each of them: every Authorization Server the work reached refuses its issuance paths, and its credentials stop being accepted everywhere within the stated time. A second Authorization Server honors the governing authorization's bounds under the trust that identity chaining already establishes, decides under its own policy, and refuses what it does not recognize. Two constraints bound any realization. It works with existing clients and authorization requests, and needs no new call from a Resource Server to the Authorization Server unless a deployment wants a shorter acceptance window. A Resource Server that already enforces scopes or authorization details, and relies on introspection or token lifetime, applies an ending without change. Full support adds refusing credentials that carry no association for the operations it protects under this framework, making those operations discoverable, and conveying why an operation is denied (). And credentials carry the least information about the work that each audience needs ().

Non-Goals A realization of this framework is not expected to: decide how an agent turns a goal into the authority it requests, any more than OAuth defines how a client chooses scopes; ensure that an agent uses authority it legitimately holds as the approver intended, which per-action authorization can address alongside it (); identify the agent or its workload; define a new authorization language, since scopes and authorization details already carry approved bounds, though each type that supports narrowing needs a defined comparison (); support joint approval by several independent parties; or undo actions already taken, or make stolen credentials useless where they are not sender-constrained.

Evaluation One scenario exercises R1 through R6 together. Any realization, or any combination of existing specifications, can be run against it: Approve two pieces of work, W1 and W2, for the same client and subject. Each holds a live access token and refresh token, none of them valid past its work's maximum lifetime. A party holding none of W1's credentials ends W1. Every issuance path for W1 refuses, including exchange of a W1 access token that has not yet expired. W2 continues unaffected. Credentials already issued for W1 stop being accepted within the acceptance window the realization states. Under W2, a token exchange asking for a $600 limit against a $500 approval is refused, and one asking for $250 succeeds. A new approval for $600 establishes a new governing authorization, and W2's approval record reads the same as before. Where W1 also reached a second Authorization Server, steps 3 and 5 hold there too, within an acceptance window that includes the remaining lifetime of any identity assertion obtained for W1 before step 2 and of any token issued on it. A Resource Server and an auditor naming W1 from one of its tokens checks R7, and a state query for W1 before and after step 2 checks R8. An ordinary token for one of W1's Resource Servers, obtained outside any governing authorization, being refused for an operation that Resource Server protects under this framework checks R9. A realization passes when every step holds without private agreements between the parties.

IANA Considerations This document makes no requests of IANA. Future revisions may propose registrations once the working group agrees on the direction.

Security Considerations Each threat below is followed by what addresses it; the cited section is the home of the corresponding rule. Forged or overreaching approval. An agent claims an approval it never obtained, or an approver approves authority they do not hold. The Authorization Server obtains the decision itself, authenticates the approver, and verifies that the approver may approve the bounds in question (). Substituted bounds. The bounds recorded or enforced differ from those disclosed to the approver. The approved bounds are the bounds disclosed, narrowed only by the approver (), and approval evidence binds the decision to them (); recording or enforcing any other bounds defeats the approval. Misleading description. The agent describes the work in terms that understate the bounds it proposes. The description restricts nothing: the approver decides on the bounds the Authorization Server discloses, and sees the description as the agent's, apart from them (). Substituted or stripped association. A credential is presented as belonging to other work, or with its association removed. A realization protects the association so that it cannot be substituted or omitted without detection, and a Resource Server refuses credentials without one for operations it protects under this framework (). Wider authority through a narrower credential. A read-only credential is used to write because the work permits writes. A credential's own restrictions continue to apply (). Stale lifecycle information. A Resource Server keeps accepting operations after the work has ended. It relies on lifecycle information only within the realization's acceptance window and denies when it cannot establish the lifecycle condition (). Operations can still be accepted within that window. Evidence replayed as permission. Approval evidence presented after the authorization has ended does not establish current authority (). Authority acquired through content. Content an agent reads under one governing authorization, including instructions embedded in it, confers no authority under that or any other authorization; a work product created under one authorization is input to work under another, which applies its own bounds. An injected instruction that leads to an operation inside the approved bounds is still permitted; that residual risk is the gap between the bounds and the work (). False completion. An agent, or a sub-agent, reports completion that has not been reached. Ending only removes authority, so this cannot widen access, but it ends the work before it is done and can leave a wrong reason on record, such as completed for work the agent abandoned. The deployment decides whose report ends the work, and the source of the recorded reason is authenticated (). Exposure of work information. Proposals and approval evidence can describe the subject's work in detail; retained or distributed evidence exposes that information to every party that receives it (). Activity beyond enforcement points. Ending an authorization denies further protected operations at participating enforcement points. It does not stop activity that uses independent authority or that another system has already accepted (). No single check carries the framework's guarantee: an operation is accepted only when every check in passes.

Privacy Considerations An identifier for a governing authorization, wherever Resource Servers receive it, lets every party that sees it correlate operations across Resource Servers and over the life of the work. A realization limits that correlation, for example by giving each audience its own reference to the authorization, and discloses the identifier only to parties that need it. The work description and the approved bounds can reveal what the subject is doing and why. A Resource Server needs the bounds that apply to it, not the description of the whole work or the bounds that apply elsewhere; a realization discloses to each party only what that party enforces or audits. Delegated work often processes data about people other than the subject, such as the customers whose records the agent in reads. The framework neither grants nor reduces their protections, and the approval does not substitute for any consent or other basis that processing their data requires. Approval evidence and the records linked to it are retained after the work ends. Their retention, and who may read them, follow the deployment's policy for records of that sensitivity.