OAuth 2.0 Bounded Work Authorization

1.1. Problem Statement

OAuth 2.0 [RFC6749] 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 [RFC7009], their state can be queried [RFC7662], and Rich Authorization Requests [RFC9396] 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.¶

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

1.2. 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" [MCP-AUTH]. 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" [MCP-EMA]. 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 [GTIG-DRIFT]. 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" [I-D.zhu-oauth-async-delegation]. 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 [I-D.ietf-wimse-aims]). 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" [I-D.chen-oauth-agent-authz-use-cases]. None of them defines what that task is to an Authorization Server.¶

1.3. 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 Section 4.2: 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 (Section 4.3, Section 4.4).¶

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 [I-D.ietf-oauth-identity-assertion-authz-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.¶

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

work:       prepare and file the Q3 pipeline report
reads:      Q3 opportunity records in the CRM, and Q3 risk
            assessments in the risk system
write:      create the report "Q3 pipeline" in Alice's CRM
            reports folder
done when:  that report is filed
ends by:    08:00 tomorrow, even if the report is never filed

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 (Section 4.3).¶

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 (Section 4.2).¶

3.2. 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 (Section 4.1.3): 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 (Section 4.2).¶

3.3. 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 [RFC7662], 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 (Section 4.4).¶

3.4. Delegating Part of the Work

At 21:00 the agent hands the risk-system reads to a sub-agent (not shown in Figure 1). It exchanges its access token for one issued to the sub-agent [RFC8693]. 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 (Section 4.2).¶

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 [RFC8693]). 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 (Section 3.6).¶

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

3.6. 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 (Section 4.4). 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 (Section 3.8): a valid credential does not authorize further operations for work that has ended, within an acceptance window the realization states.¶

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

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

The closest composition of these mechanisms uses a pushed authorization request [RFC9126] with authorization details for the approval, resource indicators [RFC8707] to narrow each token, Grant Management for one grant per piece of work, token exchange for sub-agents, and the Continuous Access Evaluation Profile [CAEP] 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 [RFC8693]). 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 [RFC8707]). For authorization details, "there is no standardized mechanism to compare two arbitrary authorization detail requests" (Section 6.1 of [RFC9396]). 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 [RFC9396]). 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" ([I-D.ietf-oauth-identity-assertion-authz-grant]), 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 Section 5.3 excludes. Such a profile would be one realization of the framework in Section 4, 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.¶

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

4.2. 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 (Section 4.3). 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 (Section 3.8), 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 [RFC8693] 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 (Section 4.4): 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.¶

4.3. 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 Section 4.2 and Section 4.4.¶

ended:

No further authority may be issued under the governing authorization, and Resource Servers apply its ending as described in Section 4.4. 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 (Section 4.4). 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 Section 4.2 and Section 4.4 succeed. Under a standing approval, ending one instance leaves the standing approval in place, and policy can activate a new instance (Section 4.2). 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.¶

4.4. 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 (Section 3.3); 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 (Section 4.2), 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 [RFC9728].¶

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 [RFC7662]), and the "invalid_token" error lets a client "request a new access token and retry" (Section 3.1 of [RFC6750]). 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 [RFC7662], 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.¶

4.5. 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 [RFC9396] provide structured authorization requests, consented permissions, and information for Resource Server enforcement, a natural carrier for a proposal's bounds.¶

• Grant Management [OAuth.GrantManagement] provides independently identifiable, queryable, and revocable concurrent grants between a client and an Authorization Server; Section 3.8 lists what it leaves undefined.¶

• The Mission specification [I-D.mcguinness-oauth-mission] 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 [I-D.liu-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 [I-D.liu-oauth-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 [I-D.liu-oauth-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 [RFC7662] and token revocation [RFC7009] are existing primitives from which resource enforcement and withdrawal can be assembled.¶

• GNAP [RFC9635] 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 [I-D.ietf-oauth-status-list], and the Shared Signals Framework [SSF] with the Continuous Access Evaluation Profile [CAEP], can deliver status changes to enforcement points before tokens expire, and so can shorten a realization's acceptance window.¶

• The identity assertion authorization grant [I-D.ietf-oauth-identity-assertion-authz-grant], identity chaining across domains [I-D.ietf-oauth-identity-chaining], and transaction tokens [I-D.ietf-oauth-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 [I-D.ietf-oauth-refresh-token-expiration] tells a client when a refresh token expires and when the underlying authorization ends.¶

• Deferred token response [I-D.ietf-oauth-deferred-token-response] lets a token request complete later, which suits an approval given while the agent waits.¶

• RAR metadata and error remediation [I-D.ietf-oauth-rar-metadata-remediation] lets a Resource Server signal insufficient authorization details, which a realization can use to report an operation outside the approved bounds (Section 4.4).¶

• AAuth [I-D.hardt-oauth-aauth-protocol] 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 [I-D.chen-oauth-agent-authz-use-cases] identifies authorization context, delegation chain, and mass revocation gaps that overlap Section 3.8.¶

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

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

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 (Section 4.4). And credentials carry the least information about the work that each audience needs (Section 8).¶

5.2. 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 (Section 4.4);¶

• 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 (Section 4.2);¶

• support joint approval by several independent parties; or¶

• undo actions already taken, or make stolen credentials useless where they are not sender-constrained.¶

5.3. Evaluation

One scenario exercises R1 through R6 together. Any realization, or any combination of existing specifications, can be run against it:¶

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

2. A party holding none of W1's credentials ends W1.¶

3. Every issuance path for W1 refuses, including exchange of a W1 access token that has not yet expired.¶

4. W2 continues unaffected.¶

5. Credentials already issued for W1 stop being accepted within the acceptance window the realization states.¶

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

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

9.1. Normative References

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

9.2. Informative References

[CAEP]

OpenID Foundation, "OpenID Continuous Access Evaluation Profile 1.0", 29 August 2025, <https://openid.net/specs/openid-caep-1_0-final.html>.

[GTIG-DRIFT]

Google Threat Intelligence Group, "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift", August 2025, <https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift>.

[I-D.chen-oauth-agent-authz-use-cases]

Chen, M., Chen, J., Yao, J., Jiang, Y., Liu, P. C., and X. Liu, "Agent Authorization use cases and gap analysis", Work in Progress, Internet-Draft, draft-chen-oauth-agent-authz-use-cases-04, 11 October 2026, <https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-authz-use-cases-04>.

[I-D.hardt-oauth-aauth-protocol]

Hardt, D., "AAuth Protocol", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-11, 25 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11>.

[I-D.ietf-oauth-deferred-token-response]

Jacobsen, F. K., de Oliveira Niero, G., and M. Gerber, "Deferred Token Response", Work in Progress, Internet-Draft, draft-ietf-oauth-deferred-token-response-00, 16 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-00>.

[I-D.ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04>.

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17>.

[I-D.ietf-oauth-rar-metadata-remediation]

Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.

[I-D.ietf-oauth-refresh-token-expiration]

Watson, N., "OAuth 2.0 Refresh Token and Authorization Expiration", Work in Progress, Internet-Draft, draft-ietf-oauth-refresh-token-expiration-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-refresh-token-expiration-03>.

[I-D.ietf-oauth-status-list]

Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-21, 21 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11>.

[I-D.ietf-wimse-aims]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-00, 15 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00>.

[I-D.liu-agent-operation-authorization]

Liu, D., Zhu, J., and S. Krishnan, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft-liu-agent-operation-authorization-02, 15 March 2026, <https://datatracker.ietf.org/doc/html/draft-liu-agent-operation-authorization-02>.

[I-D.liu-oauth-authorization-evidence]

Liu, D., Zhu, J., Krishnan, S., and A. Parecki, "Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens", Work in Progress, Internet-Draft, draft-liu-oauth-authorization-evidence-01, 22 June 2026, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence-01>.

[I-D.liu-oauth-authorization-schemas]

Liu, D., "Domain-Specific Authorization Schemas for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-authorization-schemas-00, 12 October 2026, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-schemas-00>.

[I-D.mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-00, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-00>.

[I-D.zhu-oauth-async-delegation]

Zhu, L. and Z. Berg, "Delegated Refresh Tokens for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-zhu-oauth-async-delegation-05, 3 August 2026, <https://datatracker.ietf.org/doc/html/draft-zhu-oauth-async-delegation-05>.

[MCP-AUTH]

Model Context Protocol, "Model Context Protocol: Authorization (2026-07-28)", 28 July 2026, <https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization>.

[MCP-EMA]

Model Context Protocol, "Model Context Protocol: Enterprise-Managed Authorization", 2026, <https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization>.

[OAuth.GrantManagement]

OpenID Foundation, "Grant Management for OAuth 2.0", OpenID Foundation Implementer's Draft oauth-v2-grant-management-03, 9 May 2023, <https://openid.net/specs/oauth-v2-grant-management.html>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

[SSF]

OpenID Foundation, "OpenID Shared Signals Framework Specification 1.0", 29 August 2025, <https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html>.