Mission Deferred Approval for OAuth 2.0

Status of This Memo

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 8 January 2027.¶

Copyright Notice

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

Table of Contents

1. Introduction

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

2. Status: An OPTIONAL Extension

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

3. Relationship to the Issuance Profile

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

4. Conventions and Terminology

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

Proposed Mission:

The Mission Intent and the Authority Set the Mission Issuer derived from it, pending an approval decision.¶

5. Deferred Mission Approval

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

       submit (PAR + deferred)
                |
                v
           +---------+
           | pending |
           +---------+
             |     |
   approve   |     +-------------> denied  (terminal)
             v
          approved  (terminal; Mission created active)

6. Integration with the Mission Suite

Consent evidence:

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

Shaping:

A client-side shaper ([I-D.draft-mcguinness-mission-shaping]) narrows a proposal 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.¶

Integrity anchors:

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

7. Worked Example

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

8. Conformance

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

A client conforming to this profile MUST treat every pending response as unapproved and poll the deferral_code per the deferred substrate.¶

9. Security Considerations

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

10. Privacy Considerations

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

11. IANA Considerations

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

12. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 work and profiles OAuth Deferred Token Response for asynchronous Mission approval.¶

Author's Address