| Internet-Draft | OAuth Mission Deferred Approval | August 2026 |
| McGuinness | Expires 22 February 2027 | [Page] |
Mission-Bound Authorization for OAuth 2.0 (the "issuance profile") records an approval event at which an Approver consents to a Mission's derived Authority Set, but it treats that event as immediate. A human review of an agent's Proposed Mission is often asynchronous. This document defines an optional Mission Deferred Approval profile. It profiles OAuth Deferred Token Response so a Mission approval can be deferred and polled. Deferral relocates the issuance profile's approval event to the asynchronous review surface and creates the Mission record atomically with that decision rather than with the authorization code. It relies on a core extensibility seam for approval sequencing.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission-approval/.¶
Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") derives an Authority Set from a submitted Mission Intent and records an approval event at which an Approver consents to that authority. It specifies what the approval commits, not how the approval is obtained over time. One fact about agent approval is left unspecified: a human Approver review is asynchronous. The agent submits a Proposed Mission and must wait, sometimes for a long time, for a decision.¶
This document supplies that. It profiles OAuth Deferred Token Response [I-D.draft-gerber-oauth-deferred-token-response] (the "deferred substrate") so a Mission approval can be deferred and polled.¶
A reviewer that will grant only a narrowed subset of the proposed
Mission resolves the deferral to access_denied, and the client submits
a fresh, narrower Mission Intent; an experimental companion defines an
in-place narrowing-revision handshake over this profile
([I-D.draft-mcguinness-oauth-mission-approval-revision]). Widening an
approved Mission is a different operation with its own fresh approval
([I-D.draft-mcguinness-oauth-mission-expansion]).¶
This document is optional. A deployment that obtains Mission approvals synchronously is fully conformant to the issuance profile and is unaffected by this document. It places no new requirement on the issuance profile.¶
A deployment claims this profile only when it defers Mission approvals under the deferred substrate. The approval event, the Authority Set, the subset rule, and the integrity anchors are unchanged; this document governs only how the approval is reached over time.¶
This profile is specific to the OAuth binding's authorization-code ceremony. Under the standalone Mission Authority Server binding ([I-D.draft-mcguinness-mission-authority-server]), approval is natively asynchronous and this re-sequencing is not needed.¶
This profile tracks an in-progress substrate. It depends normatively on OAuth Deferred Token Response ([I-D.draft-gerber-oauth-deferred-token-response]), an early Internet-Draft that is not ratified and whose details may change, so this profile is not yet a stable interface and will track the substrate as it evolves. Synchronous Mission approval, which needs only the issuance profile, is the stable path; deploy deferred approval for evaluation rather than as a stable interface. This document is Standards Track despite that posture because it tracks its substrate and stabilizes with it.¶
This document depends normatively on the issuance profile and on the
deferred substrate, and is not implementable alone. It reuses, without
restating, the issuance profile's Mission Intent, submission via PAR
[RFC9126], authority derivation, approval event, subset rule, and
integrity anchors, and the deferred substrate's deferral response,
continuation polling, cancellation, and sender-constraint rules. It uses
the terms Agent (Client), Approver, Mission Issuer, Mission Intent, and
Authority Set as the issuance profile defines them, and completion_mode,
deferral_code, and the deferred grant type as the deferred substrate
defines them.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Mission Intent and the Authority Set the Mission Issuer derived from it, pending an approval decision. This document uses "proposal" as shorthand for the Proposed Mission.¶
A Mission approval MAY be deferred. The client submits the Mission
Intent through PAR as the issuance profile requires, and includes
deferred among the completion_mode values on the resulting token
request, opting in to the deferred substrate
([I-D.draft-gerber-oauth-deferred-token-response]). When the Mission
Issuer cannot decide the approval immediately, for example because it
routes the Proposed Mission to a human reviewer, it returns the
substrate's deferred response (authorization_pending with a
deferral_code) instead of a token, and the client polls with the
deferred grant type until the approval resolves to a Mission-bound token
response, access_denied, or expired_token.¶
The issuance profile treats the approval event as immediate: the Approver consents and the Mission record is created atomically with issuance of the authorization code ([I-D.draft-mcguinness-oauth-mission]). For a deferred approval this profile relocates that approval event without weakening it, moving it to the asynchronous review surface:¶
The client submits the Proposed Mission via PAR [RFC9126] and the authorization request completes into a deferred state per the deferred substrate ([I-D.draft-gerber-oauth-deferred-token-response]).¶
Before approval only the pending request exists. The authorization
artifact represents a pending authorization, never authority, and no
Mission exists. A deferral_code and any PAR request_uri are
pending-request state, not a grant.¶
The approval event executes on the asynchronous review surface. That
surface MUST authenticate the Approver. It MUST satisfy the Mission
Intent's controls.acr. Both requirements hold exactly as the
synchronous approval event requires
([I-D.draft-mcguinness-oauth-mission]).¶
The Mission record is created in the active state atomically with
the approval decision, preserving the issuance profile's atomicity at
the moved point.¶
Issuance then completes per the deferred substrate: the next poll resolves to a Mission-bound token response.¶
This relocation relies on a core extensibility seam for approval sequencing, under discussion upstream. The issuance profile specifies the approval event and authorization-code issuance as one atomic step, so a deployment claims conformance to this profile's relocated sequencing rather than unqualified conformance to that original step; what the approval commits is unchanged.¶
Deferral changes only the timing of the approval event. The Authority
Set the token is issued against, its authority_hash, and the recorded
consent are exactly as in a synchronous approval. A Mission revoked
between the approval decision and the resolving poll yields no token:
issuance gating derives only from an active Mission
([I-D.draft-mcguinness-oauth-mission]). Carrying the issuance
profile's unredeemed-code rule, when the client never polls and the
deferral_code is never redeemed, the AS SHOULD revoke the orphaned
active Mission or allow it to expire
([I-D.draft-mcguinness-oauth-mission]).¶
The issuance profile runs the approval event as the OAuth
authorization-code flow initiated from the PAR-issued request_uri,
in ordered steps: authenticate the Approver, establish the Subject,
render the derived Authority Set for consent, compute the integrity
anchors, and create the Mission record atomically with issuance of the
authorization code ([I-D.draft-mcguinness-oauth-mission]). Under
deferral those steps divide between the front channel and the review
surface:¶
Authenticating the Approver, establishing the Subject, rendering for consent, and computing the integrity anchors all move to the asynchronous review surface and execute at the approval event (Section 5.1).¶
The front channel establishes only the pending request. No Approver
need be present at the authorization endpoint, and the endpoint MAY
complete the authorization request into the deferred state and issue
the authorization code without user interaction, because that code
represents a pending authorization, not authority (step 2 of
Section 5.1). The AS MUST still bind the code to the
requesting client with PKCE (S256) or issue a DPoP-bound code, as
the issuance profile requires for a front-channel code
([I-D.draft-mcguinness-oauth-mission]).¶
Subject establishment occurs on the review surface, at the approval event, together with Approver authentication, not at the front channel; the AS MUST NOT take the Subject from unauthenticated client input ([I-D.draft-mcguinness-oauth-mission]).¶
Creating the Mission record, the final step, executes atomically with the approval decision rather than with the code (Section 5.1).¶
A deferred approval is in one of these states: pending, approved,
denied, expired, or cancelled. The Mission Issuer starts a
deferred approval in pending and MAY move it to approved or
denied. The pending lifetime elapsing moves it to expired
(Section 5.4), and client cancellation under the deferred
substrate moves it to cancelled
([I-D.draft-gerber-oauth-deferred-token-response]). approved,
denied, expired, and cancelled are terminal.¶
submit (PAR + deferred)
|
v
+---------+ deny --> denied (terminal)
| pending | lifetime elapsed --> expired (terminal)
+---------+ client cancels --> cancelled (terminal)
|
approve |
v
approved (terminal; Mission created active)
¶
An experimental companion extends this state machine with a
revision_required state and a narrowing-revision handshake
([I-D.draft-mcguinness-oauth-mission-approval-revision]). Without it,
a proposal the reviewer will grant only in narrowed form resolves to
access_denied, and the client submits a fresh, narrower Mission
Intent via PAR [RFC9126].¶
A deferred approval MUST carry a deployment-set maximum pending
lifetime, after which it resolves to expired_token per the deferred
substrate. Staleness of the proposal itself needs no separate rule:
derivation is mechanical and happens once, at the approval event,
over the policy and capability catalog then in force
([I-D.draft-mcguinness-oauth-mission]), so the reviewer always
decides over an Authority Set derived and rendered under current
policy, never one derived under superseded policy.¶
An enterprise review surface is often a governance layer: several
principals, a threshold rule, and a delegation-of-authority policy
may stand behind one deferred approval. Mission Approval Governance
([I-D.draft-mcguinness-mission-approval-governance]) defines the
Approval Governance Record for exactly that state, and it is
ceremony-independent: a deployment records it for a deferred approval
under this profile precisely as for a synchronous one. Where that
document's recording triggers hold for a deferred approval, the
issuer records the Approval Governance Record joined by
approval_event_id and committed atomically with the approval
decision it governs; the pending window changes when the decision
happens, never what is recorded about it.¶
Deferral turns the review surface into a queue a client can flood. The Mission Issuer MUST bound the number of concurrent pending proposals per (client, Approver) pair, refusing further submissions until the queue drains. The Mission Issuer further:¶
SHOULD collapse pending proposals carrying an identical
intent_hash into a single review item;¶
SHOULD rate-limit reviewer notifications; and¶
SHOULD log a queue flood as a security event, alongside the decline-suppression detection the consent evidence profile describes ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶
Collapsing identical proposals is a review-surface convenience and does not merge their outcomes: one approval decision MUST resolve exactly one pending approval, and the Mission Issuer MUST re-queue or deny the others rather than mint a Mission for each. A single consent therefore mints at most one Mission.¶
Where a deployment records Consent Evidence
([I-D.draft-mcguinness-oauth-mission-consent-evidence]), a deferred
approval produces evidence exactly as a synchronous one: an approval
yields evidence with decision approved bound to the created
Mission's anchors, and a denial yields evidence with decision
declined over the proposal's anchors. The rendering the reviewer
approved on the asynchronous surface is the disclosure the evidence
commits.¶
A client-side shaper ([I-D.draft-mcguinness-mission-shaping])
narrows the Mission Intent before submission, which reduces the
chance a deferred review is refused. After an access_denied resolution, the
shaper constructs the fresh, narrower Mission Intent the client
resubmits.¶
The approval commits the proposal actually approved. The
intent_hash and authority_hash are computed over the Mission
Intent and Authority Set the Approver decided on; where the client
submitted an authority proposal, proposal_hash commits it as
submitted ([I-D.draft-mcguinness-oauth-mission]).¶
Agent s6BhdRkqt3, acting for alice, proposes a Mission to reconcile
Q3 invoices with read access to the ERP. It submits the Mission Intent
through PAR and opts in to deferral on the token request:¶
POST /token HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA& client_id=s6BhdRkqt3& completion_mode=deferred¶
The Mission Issuer routes the Proposed Mission to alice for review and
defers:¶
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{ "error": "authorization_pending",
"deferral_code": "dfc_7M2R4kP9sT1x",
"expires_in": 600, "interval": 5 }
¶
The agent polls with the deferred grant type. On review alice
approves the proposal. The Mission record is created active
atomically with her decision, and the next poll resolves to a
Mission-bound token:¶
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{ "access_token": "eyJ...",
"token_type": "DPoP",
"expires_in": 300,
"authorization_details": [
{ "type": "mission_resource_access",
"resource": "https://erp.example.com",
"actions": ["invoices.read"],
"constraints": { "period": "2026-Q3" } } ],
"mission_id": "msn_7Wq3nR8tV2xK5pL9yD4sB6zE1mC0fJ-" }
¶
The token carries the mission claim and its authority_hash as the
issuance profile defines; the response also surfaces the optional
mission_id parameter ([I-D.draft-mcguinness-oauth-mission]) for
correlation. Had alice approved only a subset, the deferral would
resolve to access_denied and the agent would submit a fresh, narrower
Mission Intent, unless the deployment runs the experimental revision
companion ([I-D.draft-mcguinness-oauth-mission-approval-revision]).¶
A Mission Issuer conforming to this profile MUST:¶
support the deferred substrate for Mission approvals it defers;¶
execute the approval event on the asynchronous review surface with the authentication the issuance profile requires (Section 5.1);¶
create the Mission record active atomically with the approval
decision; and¶
enforce the pending lifetime and staleness rules of Section 5.4 and the queue bounds of Section 5.6.¶
A Mission Issuer that records Approval Governance Records for deferred approvals does so under Mission Approval Governance's conformance ([I-D.draft-mcguinness-mission-approval-governance]).¶
A client conforming to this profile MUST treat every pending response
as unapproved and poll the deferral_code per the deferred substrate.¶
The deferred substrate's security considerations apply in full, including deferral-code entropy, sender-constraint continuity, cancellation, and oracle resistance.¶
The asynchronous review surface is part of the consent path. It MUST
meet the approval event's authentication requirements, authenticating
the Approver and satisfying the Mission Intent's controls.acr
(Section 5.1); deferring an approval does not lower the bar
the synchronous event sets. Approver routing and notification, how a
Proposed Mission reaches a reviewer and how the reviewer is alerted, are
deployment matters and are named as such here rather than specified.¶
An Approval Governance Record (Section 5.5) participates in the
approval before commitment and is evidence after it; its assertion
authentication and atomic-commitment rules live in Mission Approval
Governance ([I-D.draft-mcguinness-mission-approval-governance]).
The accountable approver on the Mission record remains the
principal every downstream check and projection uses.¶
A pending Proposed Mission reveals what authority an agent sought before any approval exists. A Mission Issuer SHOULD treat pending proposals and their resolutions as sensitive and retain them under the same controls as other approval-event records.¶
This document has no IANA actions. The deferred completion mode and
the deferred grant type are registered by the deferred substrate
([I-D.draft-gerber-oauth-deferred-token-response]).¶
This document is part of the Mission-Bound Authorization for OAuth 2.0 work and profiles OAuth Deferred Token Response for asynchronous Mission approval.¶