Web Authorization Protocol G. de Oliveira Niero, Ed. Internet-Draft Itaú Intended status: Standards Track D. Liu, Ed. Expires: 5 May 2027 Alibaba Group 1 November 2026 Deferred Token Response draft-ietf-oauth-deferred-token-response-01 Abstract This document defines the Deferred Token Response (DTR) extension for OAuth 2.1. In existing OAuth grants, the token endpoint either issues an access token or returns an error. DTR establishes a generic asynchronous token request mechanism that any OAuth grant may plug into. In DTR-aware flows, the authorization server returns a deferral_code and a polling interval, indicating that the final token response will be available at a later time. The client retrieves the eventual response by polling the token endpoint, or by receiving a callback from the authorization server when one is configured. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token- response/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token- response/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/deferred-token-response. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. de Oliveira Niero & Liu Expires 5 May 2027 [Page 1] Internet-Draft DTR November 2026 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 5 May 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Substrate Invariants . . . . . . . . . . . . . . . . . . . . 9 4.1. Substrate Guarantees . . . . . . . . . . . . . . . . . . 9 4.2. Profile Obligations . . . . . . . . . . . . . . . . . . . 10 5. Client Opt-In Signaling . . . . . . . . . . . . . . . . . . . 10 5.1. The completion_mode Parameter . . . . . . . . . . . . . . 10 5.2. Pre-Token Hints . . . . . . . . . . . . . . . . . . . . . 12 5.3. Authorization Server Discretion . . . . . . . . . . . . . 12 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 6. The Deferred Authorization Grant . . . . . . . . . . . . . . 14 6.1. Pre-Token Request . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Pre-Token Request Validation . . . . . . . . . . . . 15 6.2. Pre-Token Response . . . . . . . . . . . . . . . . . . . 15 6.3. Token Endpoint — Initial Request . . . . . . . . . . . . 15 6.3.1. Initial Request Validation . . . . . . . . . . . . . 16 6.4. Token Endpoint — Deferred Response . . . . . . . . . . . 17 6.5. Token Endpoint — Polling . . . . . . . . . . . . . . . . 19 6.5.1. Polling Request Validation . . . . . . . . . . . . . 20 de Oliveira Niero & Liu Expires 5 May 2027 [Page 2] Internet-Draft DTR November 2026 6.5.2. Successful Polling Response . . . . . . . . . . . . . 21 6.6. Token Endpoint — Error Responses . . . . . . . . . . . . 22 7. Callback Notification . . . . . . . . . . . . . . . . . . . . 24 7.1. The Callback Request . . . . . . . . . . . . . . . . . . 24 7.2. Client Registration Metadata . . . . . . . . . . . . . . 25 8. Cancellation . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Revocation Request . . . . . . . . . . . . . . . . . . . 26 8.2. Revocation Semantics for Deferral Codes . . . . . . . . . 26 8.3. Idempotency and Retry . . . . . . . . . . . . . . . . . . 27 8.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Implementation Considerations . . . . . . . . . . . . . . . . 28 9.1. Generating Deferral Codes and Notification Tokens . . . . 28 9.2. Polling and Callback Together . . . . . . . . . . . . . . 28 9.3. Obtaining an Immediate Result Alongside a Deferred Request . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.4. Progress Information in Errors . . . . . . . . . . . . . 29 9.5. Delegation to External Services . . . . . . . . . . . . . 30 10. Relationship to Other Specifications . . . . . . . . . . . . 30 10.1. Relationship to CIBA . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11.1. Sender-Constraint Requirements . . . . . . . . . . . . . 31 11.2. Replay and Theft of Deferral Codes . . . . . . . . . . . 32 11.3. Polling-Interval Denial of Service . . . . . . . . . . . 32 11.4. Callback Endpoint Validation . . . . . . . . . . . . . . 32 11.5. Callback Endpoint SSRF and Confused-Deputy Protections . . . . . . . . . . . . . . . . . . . . . . 33 11.6. Client Notification Token Handling . . . . . . . . . . . 34 11.7. Consent Staleness at Resolution . . . . . . . . . . . . 34 11.8. Logging and Disposal of Deferral Codes . . . . . . . . . 35 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 12.1. Linkability Across Polling . . . . . . . . . . . . . . . 35 12.2. Retention of deferral_code . . . . . . . . . . . . . . . 35 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 13.1. OAuth Parameters Registration . . . . . . . . . . . . . 35 13.2. OAuth Completion Mode Values Registry . . . . . . . . . 36 13.3. OAuth Dynamic Client Registration Metadata Registration . . . . . . . . . . . . . . . . . . . . . . 37 13.4. OAuth Grant Type Registry . . . . . . . . . . . . . . . 37 13.5. OAuth Authorization Server Metadata Registry . . . . . . 38 13.6. OAuth URI Registration . . . . . . . . . . . . . . . . . 38 13.7. OAuth Extensions Error Registry . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 39 14.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 42 A.1. High-Risk Transaction Evaluation . . . . . . . . . . . . 42 A.2. Step-Up Assurance During an In-Session Operation . . . . 43 A.3. Identity Verification Based on Physical Evidence . . . . 43 de Oliveira Niero & Liu Expires 5 May 2027 [Page 3] Internet-Draft DTR November 2026 A.4. Autonomous Agent Acting on Behalf of a User . . . . . . . 44 A.5. Enterprise Identity Governance Approval . . . . . . . . . 44 A.6. AI Agent with Browser Access . . . . . . . . . . . . . . 45 A.7. Regulatory Compliance . . . . . . . . . . . . . . . . . . 45 A.8. Interactive and Explicit Consent for Sensitive Operations . . . . . . . . . . . . . . . . . . . . . . . 46 Document History . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction Existing OAuth grants assume the authorization server can decide synchronously whether to issue an access token. The Authorization Code Grant (Section 4.1 of [OAUTH-2.1]), Client Credentials Grant (Section 4.2 of [OAUTH-2.1]), and assertion-based grants such as [ID-JAG] all respond to a token request with either a token response or an error response. However, some authorization decisions cannot complete synchronously: * Fraud Prevention: Sensitive operations may trigger manual review by parties other than the resource owner. * ID Verification: Users may submit copies of physical credentials during onboarding or step-up. Verification by the authorization server (or a third party acting on its behalf) can take hours. * Autonomous Agent Authorization: An agent acting on behalf of a user may request access beyond what was provisioned at enrollment, requiring out-of-band approval before the request can be granted. * Complex Authorization: Enterprise businesses often manage access controls using governance and administration workflows. Access requests may need to be approved by parties other than the resource owner. In each case, the authorization server today must return an error response, leaving the client without a mechanism to discover when (or whether) the request will eventually be approved. de Oliveira Niero & Liu Expires 5 May 2027 [Page 4] Internet-Draft DTR November 2026 This specification defines a Deferred Token Response, in which the authorization server returns a deferral_code and a polling interval in place of an access token. The deferral_code represents the pending token request and entitles the client to a final token response when the request resolves. The client either polls the token endpoint with the deferral_code, or receives a callback from the authorization server when a callback URI is registered. Unlike the Device Authorization Grant [RFC8628], deferral under DTR is initiated by the authorization server, not by the client or the end-user. This allows an authorization server to apply DTR dynamically, based on policy or risk analysis, to a request that began under another grant. The Device Authorization Grant additionally assumes that the same end-user who initiated the flow is the party who will approve it; DTR makes no such assumption, and supports use cases in which a different user, a different system, or no human at all completes the authorization decision. In many of the motivating use cases, the authorization server delegates the actual verification or decision to an external service — an identity verification vendor, a fraud analysis platform, or a governance system. The protocol between the authorization server and any such external provider is out of scope for this specification; only the interface between the client and the authorization server is defined here. 2. Conventions and Definitions 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. This specification defines the following terms: deferral code A unique, opaque, server-generated identifier that represents a single pending token request. The deferral code is carried in the deferral_code member of the deferred response (Section 6.4) and is identified, when used as a token_type_hint at the revocation endpoint, by the URI urn:ietf:params:oauth:token- type:deferral-code. The deferral code is bound to the issuing client and to a sender-constraining key per Section 11.1, and entitles the bound party to retrieve the eventual token response. polling interval The minimum number of seconds, conveyed in the de Oliveira Niero & Liu Expires 5 May 2027 [Page 5] Internet-Draft DTR November 2026 interval parameter of the deferred response, that the client MUST wait between two consecutive polling requests for the same deferral code. deferred client notification endpoint An HTTPS URI registered by the client at which it accepts callback notifications from the authorization server when a deferred request resolves. originating grant The OAuth grant — for example, the Authorization Code Grant (Section 4.1 of [OAUTH-2.1]), the Client Credentials Grant (Section 4.2 of [OAUTH-2.1]), or Token Exchange ([RFC8693]) — on whose token request the deferred response was returned, and whose successful token response shape is reused when the deferred request eventually resolves. preceding endpoint Some grant types utilize multiple authorization server endpoints. For an originating grant whose flow begins at an endpoint other than the token endpoint, the preceding endpoint is the endpoint utilized just before the token endpoint. Examples include the authorization endpoint of the Authorization Code Grant ([OAUTH-2.1]), the device authorization endpoint of [RFC8628], and the authorization challenge endpoint of [FIPA]. A grant that operates entirely at the token endpoint (for example, the Client Credentials Grant) has no preceding endpoint. 3. Overview The Deferred Token Response flow allows an authorization server to defer the issuance of an access token for an arbitrarily long time after the request that would normally produce one. The flow proceeds entirely through the originating grant's existing endpoints. A grant becomes deferred when: 1. The client signals willingness to accept a deferred response by including one of the supported values of the completion_mode parameter on the originating grant's token endpoint request. 2. The authorization server elects, on that token endpoint request, to require interaction, inform a pending interaction by the end- user or return a deferred response in place of the normal token response. The deferred response carries a deferral_code instead of an access token. 3. The client polls the token endpoint with the deferral_code until the authorization server returns the final token response, or optionally receives a callback notification when the request resolves. de Oliveira Niero & Liu Expires 5 May 2027 [Page 6] Internet-Draft DTR November 2026 For an originating grant with a preceding endpoint — for example, the authorization endpoint of the Authorization Code Grant of [OAUTH-2.1], the device authorization endpoint of [RFC8628], or the authorization challenge endpoint of [FIPA] — the client MAY also send completion_mode=deferred on the preceding request as an advance hint. The hint allows the authorization server to commit to deferral-aware behavior before the token request — for example, by collecting different consent, by showing a different verification UX, or by selecting a different review path. An authorization server that acts on the hint depends on the client's intent at the token endpoint matching it; see Section 5.2. The authorization server returns its grant's normal response to the preceding request (for example, an authorization code) regardless of whether the request will be deferred. de Oliveira Niero & Liu Expires 5 May 2027 [Page 7] Internet-Draft DTR November 2026 +--------+ +----+ +--------+ | | | | | | | |..(1) Pre-token Request.....>| | | | | | (completion_mode=deferred) | | | | | | | | | | | |--(2) Token Request--------->| | | | | | (completion_mode=deferred) | | | | | |<-(3) Deferred Response------| | | | | | (deferral_code, one of | | | | | | [A], [B] or [C]) | | | | | | | | | | | | [A] interaction_required | | | | | |--(A1) Send user to URI------|----|------------->|End-User| | | | | | | | | [B] interaction_pending | | | | | | | |-(B1) Reach-->| | | | | | out to user | | | | | | | | | | | |<-(4) Obtain->| | | | | | consent | | | | | | | | | Client |--(5) Token Request--------->| AS | | | | | (deferral_code) | | | | | |<-interaction_pending--------| | | | | | | | +--------+ | | | | | | [C] authorization_pending | | | | | | | |--(5) Token Request--------->| | | |<-authorization_pending------| | | | | |---------+ | | | | | | | | | (6) Complete request | | | | | | | | |<--------+ | | | | | |<.(7) Optional Callback......| | | | | | | |--(5) Token Request--------->| | | | (deferral_code) | | | |<-(8) Token Response---------| | | | | | +--------+ +----+ For a token-endpoint-only grant the flow is the same with steps (1) through (3) collapsed into the initial token request. de Oliveira Niero & Liu Expires 5 May 2027 [Page 8] Internet-Draft DTR November 2026 Once the authorization server has issued a deferral_code, the remaining flow — polling, callback, eventual token response, cancellation — is identical regardless of the originating grant. 4. Substrate Invariants This specification is structured as a substrate for deferred token issuance: a single continuation reference (deferral_code), a single polling state machine, and a single completion vocabulary that applies uniformly across originating grants. The invariants below state what the substrate guarantees to clients and to higher-layer profiles, and what those profiles MUST preserve when they extend it. 4.1. Substrate Guarantees An authorization server implementing this specification provides the following guarantees: 1. *No authorization expansion.* A deferral does not expand authorization beyond the originating request. Any authorization decision reached while the request is deferred can only constrain or complete the originating request. 2. *Continuation through the token endpoint.* The deferred grant type at the token endpoint is the sole client-initiated interface for advancing a deferred request, regardless of which endpoint received the originating request. 3. *Sender-constraining continuity.* Sender-constraining or proof- of-possession material from the originating request applies to every polling request and to the final token response, as defined in Section 11.1. 4. *Originating request immutability through the polling grant type.* Polling requests do not carry parameters that modify or replace parameters from the originating request. 5. *Opaque continuation reference.* Authorization servers MUST NOT encode authorization, identity, or policy decisions in the deferral_code value in a way that requires client interpretation. Clients MUST treat the deferral_code as opaque. 6. *Polling is always available as an authoritative completion path.* Continuation polling at the token endpoint is always available as an authoritative way to obtain the final token response. Callback notification and other profile-defined delivery channels MAY reduce client latency but MUST NOT replace polling as the authoritative source of the issued credentials. de Oliveira Niero & Liu Expires 5 May 2027 [Page 9] Internet-Draft DTR November 2026 4.2. Profile Obligations A higher-layer profile that extends this specification MUST preserve the substrate guarantees above and additionally MUST satisfy the following obligations: A. *State distinguishability.* Profile-defined externally-observable states MUST be mapped to token endpoint responses distinguishable from the states defined in this specification, typically via profile- defined error code values registered in the OAuth Extensions Error Registry. B. *Narrowing-only parameter updates.* A profile-defined mechanism for updating parameters preserved with a deferred request MUST operate outside the polling grant type and MUST enforce narrowing- only updates relative to the originating request. C. *No relaxation of guarantees.* A profile MAY define new completion_mode values, new externally-observable states, new response parameters, new parameter-update mechanisms, and new advisory delivery channels. A profile MUST NOT relax the no- authorization-expansion, sender-constraining-continuity, or originating-request-immutability guarantees above. A profile MUST NOT remove polling as an available authoritative completion path. 5. Client Opt-In Signaling The Deferred Token Response is an opt-in mechanism from the client's perspective. An authorization server MUST NOT issue a deferred response to a client that has not signaled willingness to accept one. This specification defines the completion_mode request parameter for that purpose. 5.1. The completion_mode Parameter completion_mode OPTIONAL. A space-separated list of completion-mode de Oliveira Niero & Liu Expires 5 May 2027 [Page 10] Internet-Draft DTR November 2026 values registered in the "OAuth Completion Mode Values" registry (Section 13). Order is not significant, and values MUST NOT be repeated. This specification defines two values, deferred and deferred_interactive. When deferred is present in the list, the client signals that it is willing to accept a deferred response from the authorization server in place of an immediate token response or error. When deferred_interactive is present in the list, the client signals that it is willing to accept a deferred response and is able to surface an interaction to the user or other external actor when the authorization server responds with interaction_required. If the parameter is absent, or is present but includes neither value, the client requires synchronous handling. The authorization server MUST ignore any value it does not recognize. The client signals opt-in to DTR by including deferred among the completion_mode values on the originating grant's token endpoint request. For an originating grant with a preceding endpoint — the authorization endpoint, the device authorization endpoint of [RFC8628], the authorization challenge endpoint, or another endpoint introduced by a future extension — the client MAY additionally send completion_mode=deferred on that preceding request as an advance hint to the authorization server. The semantics of the hint are defined in Section 5.2. An authorization server that supports the deferred token response defined in this specification and publishes Authorization Server Metadata [RFC8414] MUST include the following metadata parameter with the value true: deferred_token_response_supported Boolean value specifying whether the authorization server supports the deferred token response defined in this specification. Omission of this parameter, or a value of false, indicates no support. A client MAY discover authorization server support for this specification through the deferred_token_response_supported authorization server metadata parameter (Section 13). A client MAY send completion_mode=deferred to an authorization server that does not advertise support. Such a server MUST NOT reject the request on account of the parameter; it completes the request per its originating grant's rules, consistent with the token endpoint's handling of unrecognized parameters. de Oliveira Niero & Liu Expires 5 May 2027 [Page 11] Internet-Draft DTR November 2026 5.2. Pre-Token Hints For an originating grant with a preceding endpoint, the client MAY send completion_mode=deferred on that preceding request to inform the authorization server in advance that the grant may resolve to a deferred response at the token endpoint. The hint is optional: a client that omits it on the preceding request can still opt in at the token endpoint, and the authorization server MUST NOT reject a token request carrying completion_mode=deferred solely because no hint was received earlier. When the preceding request is an authorization request, completion_mode is conveyed like any other authorization request parameter. Examples include the request body of a Pushed Authorization Request (PAR)[RFC9126] or as a member of a JWT-secured authorization request object (JAR)[RFC9101]. An authorization server MAY act on the hint by selecting a deferral- aware path for the originating grant — for example, by collecting different consent from the resource owner, by presenting a different verification UX, by routing the request to a review queue, or by altering its risk-analysis decision. An authorization server that does not use the hint MUST treat the preceding request as it would without DTR; the hint never alters the response shape of the preceding endpoint. A client that has sent completion_mode=deferred on the preceding request MUST also include deferred among the completion_mode values on the resulting token request. If the client instead omits deferred (or omits the parameter) at the token endpoint, the authorization server MUST reject the request with the error invalid_request. A client that did not send a hint MAY still send completion_mode=deferred at the token endpoint, and the authorization server MAY return a deferred response. Polling requests (Section 6.5) are not part of the originating grant; they continue an already-deferred flow rather than initiating one and MUST NOT carry the completion_mode parameter. 5.3. Authorization Server Discretion Sending completion_mode=deferred does not entitle the client to a deferred response. The authorization server retains discretion over whether to defer any individual request — based on policy, risk analysis, or operational state — and MAY complete the request synchronously even when the client has opted in. de Oliveira Niero & Liu Expires 5 May 2027 [Page 12] Internet-Draft DTR November 2026 Conversely, an authorization server MUST NOT defer a response to a request whose completion_mode does not include deferred. In that case the authorization server completes the request synchronously per the originating grant's rules or returns an error per those rules. Authorization servers conforming to this specification MUST accept the completion_mode parameter on requests for any grant within this specification's scope; they MUST NOT reject a completion_mode value they do not recognize as an error. The opt-in semantic is preserved by the authorization server's choice of whether to defer, not by rejection of the parameter itself. 5.4. Examples Token endpoint request opting in to DTR (Authorization Code Grant): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &completion_mode=deferred Token endpoint request opting in to DTR (Client Credentials Grant): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW grant_type=client_credentials &scope=profile &completion_mode=deferred The following requests illustrate the optional pre-token hint (Section 5.2) on grants with a preceding endpoint. A client that sends a hint is expected to follow up with completion_mode=deferred on the corresponding token request shown above. Authorization endpoint hint (Authorization Code Grant of [OAUTH-2.1]): de Oliveira Niero & Liu Expires 5 May 2027 [Page 13] Internet-Draft DTR November 2026 GET /authorize?response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=profile &completion_mode=deferred &state=af0ifjsldkj HTTP/1.1 Host: server.example.com Device authorization endpoint hint (Device Authorization Grant of [RFC8628]): POST /device_authorization HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW scope=profile &completion_mode=deferred Authorization challenge endpoint hint ([FIPA]): POST /authorize-challenge HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW login_hint=%2B1-310-123-4567 &scope=profile &completion_mode=deferred 6. The Deferred Authorization Grant This section defines the protocol elements that comprise the deferred authorization grant: how the originating grant's endpoint behaves under DTR, the token endpoint request that may yield a deferred response, the polling request that retrieves the eventual token response, and the error responses returned during these exchanges. This specification defines one new grant_type URN, urn:ietf:params:oauth:grant-type:deferred, used only on polling requests (Section 6.5) to retrieve a deferred token response. The originating grant's existing grant_type (for example, authorization_code or client_credentials) is unchanged on the token endpoint request that may yield a deferred response. de Oliveira Niero & Liu Expires 5 May 2027 [Page 14] Internet-Draft DTR November 2026 6.1. Pre-Token Request For grants that have a preceding endpoint, the client MAY send completion_mode=deferred on the originating grant's request to that endpoint as the optional pre-token hint defined in Section 5.2. The preceding endpoint behaves identically with or without completion_mode: the authorization server returns the originating grant's normal response and does not include any DTR-specific parameter. The following is a non-normative example of an authorization-endpoint hint under DTR (line wraps within values are for display only): GET /authorize?response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=profile &completion_mode=deferred &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 6.1.1. Pre-Token Request Validation The authorization server MUST validate the request as it would without DTR, with the following addition: * Apply the completion_mode rules of Section 5.1: process recognized values, ignore unrecognized ones, and treat the request as requiring synchronous handling if the parameter is absent or does not include deferred. If the authorization server encounters any error, it MUST return the originating grant's normal error response. 6.2. Pre-Token Response The authorization server returns the originating grant's normal response to a preceding-endpoint request, regardless of whether the request carried a completion_mode=deferred hint. For the Authorization Code Grant of [OAUTH-2.1], this is the authorization code response of Section 4.1.2 of [OAUTH-2.1]. The client processes the response per the originating grant's rules. 6.3. Token Endpoint — Initial Request The initial token request is the originating grant's token request, extended with the completion_mode parameter from Section 5. de Oliveira Niero & Liu Expires 5 May 2027 [Page 15] Internet-Draft DTR November 2026 The client MAY also include the following parameter: client_notification_token OPTIONAL. An opaque bearer credential generated by the client. If present, the authorization server MUST bind it to the resulting deferral code and MUST present it as a Bearer token on any callback notification for that deferral code (see Section 7.1). The token MUST contain sufficient entropy to make brute-force guessing infeasible (a minimum of 128 bits, with 160 bits RECOMMENDED), following Section 9.1 guidelines. A client that registers a deferred_client_notification_endpoint SHOULD include a client_notification_token; without one, the client cannot authenticate inbound callbacks (see Section 11.4). The response to this request is one of: * The originating grant's normal token response per Section 5.1 of [OAUTH-2.1], if the authorization server completes the request synchronously. * The deferred response defined in Section 6.4, if the authorization server elects to defer the request. The deferred response is an error response that carries a deferral_code the client uses for polling. The following is a non-normative example of an initial token request under DTR for the Authorization Code Grant: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &completion_mode=deferred &client_notification_token=5SIVTd4ZzzGctFQr4AqOGdCgyIa40-tCepd-0AcZxFY 6.3.1. Initial Request Validation The authorization server MUST validate the request as it would without DTR, with the following additions: * Apply the completion_mode rules of Section 5.1: process recognized values and ignore unrecognized ones; if the parameter is absent or does not include deferred, treat the request as requiring synchronous handling. de Oliveira Niero & Liu Expires 5 May 2027 [Page 16] Internet-Draft DTR November 2026 * If the originating grant has a preceding endpoint and the client sent completion_mode=deferred on that earlier request, apply the hint-consistency rule of Section 5.2: if the token request does not also include deferred in completion_mode, the authorization server MUST reject the request with the error invalid_request. If the authorization server encounters any error, it MUST return an error response per Section 6.6 or per the originating grant's rules, as appropriate. 6.4. Token Endpoint — Deferred Response When the authorization server elects to defer a token request whose completion_mode includes deferred, it returns an error response on the token endpoint per Section 5.2 of [OAUTH-2.1] with the HTTP status code 400 (Bad Request) and the error code authorization_pending. The deferred response is not a token response: it issues no access token and confers no access to any protected resource. Instead it carries a deferral_code that the client uses to retrieve the eventual token response once the deferred request resolves. A deferral code is a sender-constrained, AS-issued credential that represents a single pending authorization request. It is not an OAuth access token, refresh token, or authorization code, and it confers no access to any protected resource. Its use is strictly limited to interacting with the same authorization server regarding the pending authorization request it represents. See Section 6.5. In addition to the error parameter, the deferred response includes the following parameters: deferral_code REQUIRED. The deferral code issued by the authorization server. The deferral code MUST contain at least 128 bits of entropy (160 bits RECOMMENDED) drawn from a cryptographically secure random source per Section 10.10 of [RFC6749]. See Section 9.1 for construction guidance. The deferral code MUST be opaque to the client and MUST NOT carry meaning visible to the client. The client uses this value when polling the token endpoint per Section 6.5 and, if a deferred_client_notification_endpoint is registered, the authorization server includes the same value when it notifies the client. expires_in REQUIRED. The lifetime in seconds of the deferral code. de Oliveira Niero & Liu Expires 5 May 2027 [Page 17] Internet-Draft DTR November 2026 After this interval, the authorization server MUST reject polling requests that present this deferral code with the error expired_token. This value governs the lifetime of the deferral code, not the lifetime of any eventual access token; clients MUST NOT use this value to schedule access-token refresh. interval REQUIRED. The minimum number of seconds the client MUST wait between polling requests, following the semantics of the interval field defined in Section 3.2 of [RFC8628]. The interval is carried only in the deferred response; subsequent polling responses with authorization_pending do not repeat it, and the client MUST retain the value from the deferred response for the lifetime of the deferral code. error_description OPTIONAL. Human-readable text as defined in Section 5.2 of [OAUTH-2.1], subject to the data-minimization rules of Section 9.4. interaction_uri OPTIONAL on initial deferred responses and on polling responses carrying authorization_pending. REQUIRED on responses carrying interaction_required (Section 6.6). When present, the value MUST be an HTTPS URI, MUST NOT contain a fragment component, and identifies a location where external interaction associated with the deferred request can take place. This specification does not define the semantics of the interaction. Higher-layer profiles MAY constrain the URI's origin, define the interaction protocol, or attach additional context. The authorization server MUST bind the interaction_uri to the associated deferral state; accessing the URI MUST NOT by itself authorize the originating request or complete the deferred processing. Completion occurs only when the authorization server updates the deferral state per its own rules. The authorization server MUST make interaction_uri values single- use or otherwise resistant to replay, and MUST limit their lifetime to no longer than the lifetime of the associated deferral code. Clients MUST treat the value as opaque. Example: de Oliveira Niero & Liu Expires 5 May 2027 [Page 18] Internet-Draft DTR November 2026 HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "authorization_pending", "deferral_code": "LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4", "expires_in": 10800, "interval": 60 } A deferred response that is waiting on external interaction is returned with the interaction_required error code and an interaction_uri parameter: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "interaction_required", "deferral_code": "LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4", "interaction_uri": "https://as.example.com/interact/PK5U1OyuHKyiEJIg7mPXJn2J", "expires_in": 10800, "interval": 60 } The authorization server MUST sender-constrain the deferral code following the rules of [RFC9449], Section 5 for refresh tokens: when the initial token request that produced the deferred response was bound to a DPoP key (or to a TLS client certificate per [RFC8705]), the deferral code is bound to the same key. Polling requests presenting this deferral code MUST be authenticated with the same key (see Section 6.5). Future profiles of this specification MAY add additional response parameters alongside the parameters defined here. Such parameters are out of scope for this document. 6.5. Token Endpoint — Polling Once the client has a deferral_code from the deferred response of Section 6.4, the client polls the token endpoint until the request resolves. de Oliveira Niero & Liu Expires 5 May 2027 [Page 19] Internet-Draft DTR November 2026 The polling request is a token endpoint request that does not derive from the originating grant; it carries only the deferral_code and this specification's polling grant type. The client makes an HTTP POST request to the token endpoint with the parameters using the application/x-www-form-urlencoded format: grant_type REQUIRED. Value MUST be urn:ietf:params:oauth:grant- type:deferred. deferral_code REQUIRED. The deferral_code issued in the deferred response. The client authenticates to the token endpoint as required by its registered authentication method per Section 2.4 of [OAUTH-2.1]. The client MUST NOT send polling requests faster than the rate established by the interval parameter of the deferred response. The client MUST increase the interval in response to a slow_down error (Section 6.6) by at least 5 seconds. The following is a non-normative example: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW grant_type=urn:ietf:params:oauth:grant-type:deferred &deferral_code=LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4 6.5.1. Polling Request Validation The authorization server MUST validate the request: 1. Authenticate the client per Section 2.4 of [OAUTH-2.1]. 2. Verify that the deferral_code is recognized and was issued to the authenticated client. If not, return invalid_grant. 3. If the request is still pending, verify that expires_in has not elapsed. If it has, return expired_token. 4. Evaluate the resolution state of the deferred request: * If the request has resolved successfully, return the token response defined in Section 6.5.2. de Oliveira Niero & Liu Expires 5 May 2027 [Page 20] Internet-Draft DTR November 2026 * If the request has resolved with an error or has been cancelled per Section 8, return access_denied. 5. Verify that no token response has previously been issued for this deferral_code. If it has, return invalid_grant. If the authorization server encounters any error, it MUST return an error response per Section 6.6. 6.5.2. Successful Polling Response When the deferred request has resolved successfully, the authorization server returns the originating grant's successful token response per Section 5.1 of [OAUTH-2.1]. The response includes an access_token, a token_type, and any other fields the originating grant defines (such as refresh_token or scope). When the originating grant defines an issued_token_type in its successful token response (as Token Exchange does, per Section 2.2.1 of [RFC8693]), the successful polling response carries that originating-grant issued_token_type value. The successful polling response is never a deferred response and MUST NOT carry the urn:ietf:params:oauth:token-type:deferral-code type. The expires_in field of this response carries the access-token lifetime per Section 5.1 of [OAUTH-2.1]; it is not the deferral-code lifetime conveyed by expires_in in the earlier deferred response. A deferral_code that has been redeemed for a successful response is no longer valid; subsequent polling requests with the same deferral_code MUST be rejected with invalid_grant. The following is a non-normative example: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "8xLOxBtZp8" } de Oliveira Niero & Liu Expires 5 May 2027 [Page 21] Internet-Draft DTR November 2026 6.6. Token Endpoint — Error Responses If a token-endpoint request defined by this specification — the initial request of Section 6.3 or the polling request of Section 6.5 — is invalid, unauthorized, or pending, the authorization server returns an error response per Section 5.2 of [OAUTH-2.1]. The authorization server MUST include the Cache-Control: no-store header field from Section 5.2.2.3 of [RFC7234] in every error response defined in this section, including the deferred response of Section 6.4 and any authorization_pending or slow_down response. This prevents an intermediary or the client from caching a transient authorization_pending response and replaying it, which could otherwise cause the client to poll indefinitely. In addition to the error codes defined in Section 5.2 of [OAUTH-2.1], this specification uses the following error codes, with semantics aligned with the corresponding codes in Section 3.5 of [RFC8628]: authorization_pending The request has not yet resolved and is not waiting on external interaction. On the initial token request, this is the deferred response of Section 6.4, which establishes the deferral_code and carries expires_in and interval. On a subsequent polling request, it indicates the deferred request is still pending; such responses reference the established deferral_code and do not repeat it. In either case the client SHOULD continue polling at the rate established by interval. interaction_required The deferred request is pending and cannot continue until external interaction associated with the request occurs. The response MUST include an interaction_uri parameter (Section 6.4) that identifies a location where the interaction can take place. A client receiving this response SHOULD present the interaction_uri to the user (or other external actor) as appropriate for the application and continues polling at the rate established by interval. This specification uses the interaction_required error code with the token endpoint semantics defined here. The error name is registered in the OAuth Extensions Error Registry by [OIDC-CORE] for authorization endpoint use; the IANA action in Section 13 updates that registration to add token endpoint response usage. interaction_pending The deferred request is pending, and the external interaction associated with it has already been initiated, either by the client (for example, the user has been directed to the interaction_uri) or by the authorization server, but has not yet completed. The authorization server MUST return de Oliveira Niero & Liu Expires 5 May 2027 [Page 22] Internet-Draft DTR November 2026 this error only when it can observe that the interaction has begun. A client SHOULD continue polling at the rate established by interval. authorization_pending, interaction_required, and interaction_pending are non-terminal pending states. A client MUST NOT treat these states as terminal. slow_down The client is polling faster than interval allows. The client MUST increase its polling interval as described in Section 6.5. expired_token The deferral_code has expired. The client MUST stop polling with this deferral_code and MAY initiate a new flow. access_denied The deferred request was denied — for example, because the authorization could not be granted, or because the request was cancelled per Section 8. The following additional rules apply: * A deferral_code that is not recognized, was issued to a different client, or has already been redeemed MUST result in an invalid_grant error per Section 3.2.4 of [OAUTH-2.1]. When the server has confirmed that the deferral code was issued to the authenticated client, the error_description SHOULD distinguish between "already redeemed" and "unknown identifier" for diagnostic purposes. When the deferral code is unrecognized or was issued to a different client, the server MUST treat it as unknown and MUST NOT provide detail that would allow distinguishing these cases. Clients MUST treat all invalid_grant responses as terminal and MUST NOT retry with the same deferral_code. * A token request that omits deferred from completion_mode after a completion_mode=deferred hint was sent on the originating grant's preceding-endpoint request MUST result in an invalid_request error per Section 5.2. * If a client polls faster than interval repeatedly, the authorization server MAY escalate from slow_down to invalid_request. A client receiving invalid_request MUST NOT make further requests with the same deferral_code. The data-minimization rules of Section 9.4 apply to the error_description field of any error response defined in this section, including authorization_pending responses that carry progress information. de Oliveira Niero & Liu Expires 5 May 2027 [Page 23] Internet-Draft DTR November 2026 The following is a non-normative example: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "authorization_pending", "error_description": "The deferred request is still being processed." } 7. Callback Notification A client that does not wish to poll for the result of a deferred request MAY register a deferred_client_notification_endpoint (Section 7.2) at which it accepts callback notifications from the authorization server. When the deferred request resolves — successfully, with an error, or by cancellation — the authorization server sends a callback notification to that endpoint. A callback notification does not itself convey the token response or any credential. It indicates that polling the token endpoint with the deferral_code will now yield a final response. An authorization server MUST NOT initiate a callback notification before the HTTP response carrying the deferred response that introduced the deferral_code has been written to the network. Authorization servers SHOULD additionally delay callbacks for a small implementation-defined period after that point so that the client can record the deferral_code before receiving notice of its resolution. The authorization server MUST NOT send a callback notification for a deferral_code that has already expired; the client is informed of expiration via the expires_in value in the deferred response. 7.1. The Callback Request The callback is an HTTP POST to the registered deferred_client_notification_endpoint with the following parameter encoded in application/json: deferral_code REQUIRED. The deferral_code of the deferred request that has resolved. If the client supplied a client_notification_token on the initial token request that produced this deferral code, the authorization server MUST authenticate the callback request by including the client_notification_token as a Bearer credential in the Authorization de Oliveira Niero & Liu Expires 5 May 2027 [Page 24] Internet-Draft DTR November 2026 header per Section 2.1 of [RFC6750]. The client MUST validate that the bearer credential equals the client_notification_token it supplied; on mismatch, the client MUST respond with HTTP 401 Unauthorized. If the client did not supply a client_notification_token, the authorization server MUST omit the Authorization header. In that case the client MUST protect the callback endpoint by some other means — for example, mutual TLS or network-position assumptions — and SHOULD treat the callback as advisory until it has confirmed resolution by polling the token endpoint with the deferral code. The following is a non-normative example with client_notification_token: POST /cb HTTP/1.1 Host: client.example.com Authorization: Bearer 5SIVTd4ZzzGctFQr4AqOGdCgyIa40-tCepd-0AcZxFY Content-Type: application/json { "deferral_code": "LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4" } For valid requests, the client MUST respond with HTTP 204 No Content. The client MUST NOT respond with an HTTP 3xx status code; the authorization server MUST NOT follow redirects. Handling of HTTP error codes in the 4xx and 5xx ranges by the authorization server is out of scope for this specification. Clients receiving a callback notification MUST ignore unrecognized parameters in the callback body. 7.2. Client Registration Metadata The following Client Metadata parameter is defined by this specification to be used during Client Registration as defined in [RFC7591]: deferred_client_notification_endpoint OPTIONAL. URL to which the authorization server sends a notification when a deferred authorization request resolves. If supplied, it MUST be an HTTPS URL. A client that does not register this endpoint retrieves the final token response by polling the token endpoint. de Oliveira Niero & Liu Expires 5 May 2027 [Page 25] Internet-Draft DTR November 2026 8. Cancellation A client MAY cancel a pending deferred request to release authorization server resources or because the underlying user intent no longer applies. Cancellation is performed by revoking the deferral code at the authorization server's revocation endpoint per [RFC7009]. 8.1. Revocation Request The client makes an HTTP POST request to the revocation endpoint per Section 2.1 of [RFC7009], with the following parameters using the application/x-www-form-urlencoded format: token REQUIRED. The deferral code to cancel, exactly as received in the deferral_code field of the deferred response. token_type_hint RECOMMENDED. Value urn:ietf:params:oauth:token- type:deferral-code. The client authenticates to the revocation endpoint as required by its registered authentication method per Section 2.4 of [OAUTH-2.1]. The following is a non-normative example: POST /revoke HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW token=LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4 &token_type_hint=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Adeferral-code 8.2. Revocation Semantics for Deferral Codes Authorization servers MUST extend the revocation endpoint to accept deferral codes, with the following semantics: 1. If the deferral code is recognized and was issued to the authenticated client, the authorization server MUST atomically transition the pending request to a cancelled state, MUST suppress any pending callback notification for the deferral code where delivery has not yet been initiated, and MUST cause subsequent polling requests against the deferral code to return access_denied per Section 6.6. de Oliveira Niero & Liu Expires 5 May 2027 [Page 26] Internet-Draft DTR November 2026 2. If the deferral code is unrecognized, was issued to a different authenticated client, or has already been redeemed, cancelled, or expired — the authorization server MUST return HTTP 200 OK without modifying state. Invalid tokens do not cause an error response, per Section 2.2 of [RFC7009]. 3. If the deferred request has already resolved successfully and the resulting access token has been delivered to the client, the authorization server MUST NOT revoke that access token as a side effect of revoking the deferral code. The two are independent credentials with independent lifetimes; clients that need to revoke an issued access token MUST do so explicitly per [RFC7009]. 4. If the deferred request has resolved successfully but the access token has not yet been delivered to the client (for example, a resolution committed between the last poll and the cancellation), the authorization server MUST treat the deferral code as redeemed-and-then-cancelled: it MUST NOT issue the access token on any subsequent polling request and MUST return access_denied instead. The revocation response is governed by Section 2.2 of [RFC7009]. After a successful cancellation, the authorization server MAY retain the deferral code's identifier for the remainder of expires_in to ensure that subsequent polling requests reliably return access_denied rather than invalid_grant. Disposal of any data collected during the deferred request is out of scope for this specification. To avoid leaking the validity of deferral code identifiers through response timing, authorization servers SHOULD process revocation requests in approximately constant time regardless of whether the supplied token value is recognized. This complements the indistinguishability of the response codes required by clauses 1 and 2 above. 8.3. Idempotency and Retry Per Section 2.2 of [RFC7009], the revocation endpoint is idempotent. Clients MAY retry revocation requests on transport failures without risking adverse effects. de Oliveira Niero & Liu Expires 5 May 2027 [Page 27] Internet-Draft DTR November 2026 8.4. Discovery To allow clients to determine whether the revocation endpoint accepts deferral codes, this specification registers the authorization server metadata parameter revocation_endpoint_token_type_values_supported in Section 13. An authorization server that supports this specification MUST list urn:ietf:params:oauth:token-type:deferral-code in this array. Clients SHOULD check that urn:ietf:params:oauth:token-type:deferral- code is present in revocation_endpoint_token_type_values_supported before relying on cancellation. An authorization server that does not advertise support will return HTTP 200 OK for any revocation request per Section 2.2 of [RFC7009], which is indistinguishable from a successful cancellation. Clients that skip this check risk silently failing to cancel a pending deferred request. 9. Implementation Considerations 9.1. Generating Deferral Codes and Notification Tokens The entropy requirements in Section 6.4 and Section 6.3 constrain how unpredictable the value is, not the length in its encoded form. An implementation satisfies them by drawing the required number of bits from a cryptographically secure random source and encoding the result. A conforming construction is to draw 16 octets (20 octets to meet the RECOMMENDED 160 bits) from a cryptographically secure random source and encode them with base64url without padding (Section 5 of [RFC4648]). UUIDs are a recurring source of non-compliance. A version 4 UUID is 128 bits wide but carries at most 122 bits of randomness, because the version and variant fields are fixed (Section 5.4 of [RFC9562]), and other versions spend further bits on timestamps and node identifiers. [RFC9562] also does not require those bits to be drawn from a cryptographically secure source. Meeting the entropy requirement is the responsibility of the party that generates the value, and attempts by the receiving party to verify it are inherently unreliable. 9.2. Polling and Callback Together A client that has registered a deferred_client_notification_endpoint SHOULD continue to poll the token endpoint at the rate established by interval, rather than rely solely on the callback. Polling provides resilience against lost or delayed callbacks and limits the impact of a compromised callback endpoint that suppresses inbound notifications. de Oliveira Niero & Liu Expires 5 May 2027 [Page 28] Internet-Draft DTR November 2026 A client awaiting a deferred request whose expires_in is close to elapsing MAY send a final polling request slightly before the expiration, to mitigate the risk of a resolution that occurs too late to fall within the normal polling schedule. This specification does not define a way to deliver the final token response directly via the callback. Long-running, high-value flows warrant the durability of polling: a single lost push request would otherwise lose the outcome of the entire deferred request. 9.3. Obtaining an Immediate Result Alongside a Deferred Request A deferred request may take an arbitrarily long time to resolve. A client that also requires an immediate result — for example, a basic access token or an ID token to render initial user experience — can obtain one by starting a separate, non-deferred grant in parallel, while it continues to poll the deferred request for the final result. How the client obtains the immediate result depends on the originating grant: * For the Authorization Code Grant, the client can perform a parallel OpenID Connect authentication with prompt=none to obtain an ID token (and, where applicable, an access token) without further user interaction. * For the Client Credentials Grant or [ID-JAG], the client can send an additional token request that omits the completion_mode parameter entirely, which the authorization server completes synchronously per the originating grant's rules. The immediate result and the deferred result are independent: the immediate result reflects what the authorization server can issue synchronously, while the deferred request continues toward the final, possibly higher-assurance, token response. This lets a client proceed with available work immediately rather than blocking on the deferred outcome. 9.4. Progress Information in Errors When responding to a polling request with authorization_pending, the authorization server SHOULD include progress information in the error_description field where appropriate. Examples include the current step in a multi-step process, the queue position of the deferred request, or an estimate of remaining processing time. de Oliveira Niero & Liu Expires 5 May 2027 [Page 29] Internet-Draft DTR November 2026 Authorization servers MUST NOT include personal data, document identifiers, or any data subject to data-minimization obligations in the error_description field. Progress information SHOULD be expressed as opaque step identifiers (for example, step=document_review) rather than free-form descriptions of user content. The client MAY surface this information to a human operator if appropriate. Progress information is informational and the client MUST NOT depend on its presence or format. 9.5. Delegation to External Services An authorization server may rely on one or more external services to resolve a deferred request — for example, an identity verification vendor, a fraud analysis system, a human review queue, or an enterprise governance platform. This specification does not define or constrain the trust relationship between the authorization server and any such service. From the client's perspective the authorization server remains the sole counterparty: the client has no direct relationship with, and need not be aware of, any external service involved in resolving the deferred request. 10. Relationship to Other Specifications This section is informative. 10.1. Relationship to CIBA This specification overlaps in mechanism with OpenID Connect Client- Initiated Backchannel Authentication (CIBA) [CIBA]: both issue an opaque identifier (CIBA's auth_req_id, this specification's deferral code), both define a polling mode governed by an interval parameter, and both define a callback notification that signals the client to retrieve the result. The differences are intentional. Initiation model. CIBA is initiated by the client. DTR is not initiated by a client at all: an existing grant is initiated by its normal means and the authorization server elects to defer the resulting token response. CIBA cannot express deferral of a Client Credentials Grant or a Token Exchange ([RFC8693]) request, because CIBA's initiation inherently requires an end-user; this specification can, because deferral is decided at the token endpoint without regard to the originating grant's initiation pattern. de Oliveira Niero & Liu Expires 5 May 2027 [Page 30] Internet-Draft DTR November 2026 User model. CIBA is a user authentication specification. CIBA requires the client to identify the user that must be contacted, using parameters such as login_hint or id_token_hint. CIBA cannot express situations where the authorization server wishes to choose the user or system to contact dynamically. 11. Security Considerations This specification builds on the security model of OAuth 2.1 (Section 7 of [OAUTH-2.1]) and the OAuth Security Best Current Practice ([RFC9700]). The considerations in those documents apply. The following considerations are specific to this specification. 11.1. Sender-Constraint Requirements Deferral codes have lifetimes that may extend for hours or days. Over that window, a stolen deferral code combined with compromised client credentials would allow an attacker to retrieve the eventual access token. For a confidential client, sender-constraining provides a defense-in-depth layer: even if both the deferral code and the client credentials are exposed, the attacker cannot redeem the code without the bound DPoP private key or mTLS certificate. For a public client, which has no client credentials to compromise, sender- constraining is the primary defense against a stolen deferral code rather than an additional layer, which is why the binding below is mandatory for such clients. A client that is a public client per Section 2.1 of [OAUTH-2.1], or that is using an originating grant whose security profile mandates DPoP (for example, a profile that adopts [RFC9449] as a requirement), MUST present a DPoP proof on the initial token request that yields a deferred response. A confidential client using a strong client authentication method — for example, mutual TLS per [RFC8705] or private_key_jwt — MAY omit DPoP. A confidential client using a weaker client authentication method (client_secret_basic or client_secret_post) SHOULD bind the deferral code with DPoP. When DPoP is presented on the initial token request, the authorization server MUST persist the JWK Thumbprint (Section 6.1 of [RFC9449]) of the proof key. Every subsequent polling request and revocation request that presents the resulting deferral code MUST carry a DPoP proof signed by the same key. The authorization server MUST reject any request whose proof does not chain to the persisted thumbprint with the error invalid_dpop_proof (Section 7 of [RFC9449]). de Oliveira Niero & Liu Expires 5 May 2027 [Page 31] Internet-Draft DTR November 2026 When the deferred request resolves and an access token is issued in response to a polling request, the issued access token MUST be DPoP- bound to the same key, consistent with Section 5 of [RFC9449]. A confidential client that did not bind the deferral code with DPoP likewise inherits its originating grant's access-token binding rules unchanged. The callback notification path is not authenticated by DPoP; the post-callback polling request is the moment of redemption and is covered by the rules above. 11.2. Replay and Theft of Deferral Codes A deferral code is sender-constrained per Section 11.1, inheriting the binding rules of Section 5 of [RFC9449] for refresh tokens. Its threat profile is the same as a refresh token of equivalent lifetime; the considerations of [RFC9449] apply unchanged. As described in Section 11.1, redeeming a stolen deferral code also requires the client credentials it is bound to, and the sender-constraining key provides a further layer of protection; for a public client the sender-constraining key is the primary such protection. The originating grant's credentials — for example, the authorization code returned to a client that requested response_type=code — are unaffected by DTR and remain subject to the same protections as in the non-deferred case (Section 4.1.3 of [OAUTH-2.1], Section 2.1.1 of [RFC9700]). 11.3. Polling-Interval Denial of Service Misbehaving or compromised clients may poll faster than the announced interval, consuming authorization server resources. Authorization servers SHOULD respond to faster-than-interval polling with slow_down initially and MAY escalate to invalid_request for clients that persist; a client receiving invalid_request MUST stop polling for the affected deferral_code. Authorization servers MAY also impose per- client and per-flow rate limits independent of the announced interval. 11.4. Callback Endpoint Validation The deferred_client_notification_endpoint registered by a client is an inbound surface from the authorization server. Authorization servers MUST require that the registered URI is an HTTPS URL. When the client supplies a client_notification_token on the initial token request, the bearer credential presented in the callback's Authorization header authenticates the authorization server to the de Oliveira Niero & Liu Expires 5 May 2027 [Page 32] Internet-Draft DTR November 2026 client (see Section 7.1). Even so, the callback carries no authorization grant: clients MUST retrieve the resolution by polling the token endpoint with the deferral code after a callback, not solely on the basis of having received the callback. Treating the callback alone as authoritative would allow a denial-of-service attacker who can cause callbacks to skip polling and miss the actual authorization decision. A client that does not supply a client_notification_token cannot authenticate inbound callbacks at the application layer. Such a client MUST protect the callback endpoint by other means (mutual TLS, network-position assumptions, or a private network) and MUST treat any callback as advisory. 11.5. Callback Endpoint SSRF and Confused-Deputy Protections The authorization server, on every callback, makes an outbound HTTP request to a client-controlled URL. Without further protections this would be a server-side request forgery (SSRF) surface: an attacker who can register a deferred_client_notification_endpoint could coerce the authorization server into probing internal infrastructure. The protections below are analogous to the redirect-URI hardening of Section 4.1 of [RFC9700] and to common SSRF mitigations from deployed CIBA ([CIBA]) implementations. At registration time, the authorization server SHOULD reject a deferred_client_notification_endpoint whose hostname resolves to a private (RFC 6890), loopback, link-local, or unspecified address. Development and test deployments where such addresses are intentional are an explicit exception; production deployments SHOULD enforce the restriction. At delivery time, the authorization server SHOULD re-resolve the hostname and verify that all returned addresses are public (subject to the same exception). To defeat DNS rebinding, the authorization server SHOULD pin the resolved address for the lifetime of the callback connection rather than rely on the resolver's cached entry. The authorization server SHOULD set a finite connect and read timeout on the callback request and SHOULD cap the maximum response body size it is willing to read. The specification already requires the authorization server to ignore any HTTP response body (Section 7.1); the size cap exists to bound resource consumption from a misbehaving or malicious endpoint. The authorization server MUST NOT include the deferral_code, the client_notification_token, or any other token material in the callback URL path or query string. The deferral_code is conveyed in de Oliveira Niero & Liu Expires 5 May 2027 [Page 33] Internet-Draft DTR November 2026 the JSON request body and the client_notification_token, if present, is conveyed in the Authorization header per Section 7.1; placing either in the URL would expose the value to web-server access logs, intermediary proxies, and Referer headers on any subsequent request the client emits. 11.6. Client Notification Token Handling A client_notification_token is a long-lived shared secret between the client and the authorization server: it persists from the initial token request until the deferral code expires or is revoked, which may be hours or days. Both parties MUST treat it with the storage and disposal care appropriate to a refresh token of equivalent lifetime (Section 6 of [RFC9700]). Authorization servers MUST dispose of the token when the deferral code resolves, expires, or is revoked. Clients MUST NOT log the token or expose it through error messages. A client_notification_token is bound to a single deferral code. Clients MUST generate a fresh token for each initial token request that opts into DTR; reuse across requests collapses the per-request binding and weakens the protection that the token provides. 11.7. Consent Staleness at Resolution Deferral codes are designed to allow expires_in values measured in hours or days. Across that window the resource owner's consent at the moment of the originating grant may diverge from their state at the moment of resolution: the owner may have changed credentials, revoked the client, had their account suspended, or otherwise altered the preconditions that justified the grant. Before issuing a token in response to a successful polling request, the authorization server MUST re-evaluate that the resource owner's consent and the client's authorization remain valid. If consent has been revoked, the client has been disabled, the resource owner's session has been terminated, or any precondition of the originating grant no longer holds, the authorization server MUST return access_denied per Section 6.6 and MUST NOT issue an access token. This is the deferred-grant analogue of Section 4.6 of [RFC9700]. de Oliveira Niero & Liu Expires 5 May 2027 [Page 34] Internet-Draft DTR November 2026 11.8. Logging and Disposal of Deferral Codes A deferral code carries the same sensitivity as a refresh token for the duration of expires_in. Authorization servers and clients MUST NOT log deferral code values in plaintext beyond the code's lifetime, and SHOULD apply the same log redaction, transport security, and at- rest storage protections they apply to refresh tokens. Standard web- server access logs that capture POST bodies retain deferral code values for the entire log retention window; implementations SHOULD configure their logging stacks to redact the deferral_code parameter wherever it appears — both as the polling request parameter and as the response field of deferred responses (see Section 6.4). 12. Privacy Considerations 12.1. Linkability Across Polling Each polling request from a client to the token endpoint is identifiable to the authorization server via the client's authenticated identity and the deferral_code. For long-running deferred requests, the polling pattern itself (timing, network origin, user-agent of the client) may be observable to network intermediaries, even though the deferral_code is sent over TLS. Clients SHOULD avoid embedding distinguishing information in client- controlled fields that travel with polling requests. 12.2. Retention of deferral_code Authorization servers retain deferral_code values, and any associated context required to complete the deferred request, for the lifetime indicated by expires_in. Authorization servers SHOULD retain only the data necessary to complete the request and to satisfy the cancellation and audit requirements of this specification, and SHOULD dispose of deferral_code values and their associated state once the request has resolved or expired. Disposal of any data collected during the deferred request itself is out of scope. 13. IANA Considerations This section requests registrations in IANA registries as listed below. Final values for Reference are this RFC once published. 13.1. OAuth Parameters Registration This specification requests registration of the following parameters in the IANA "OAuth Parameters" registry: * Parameter name: completion_mode de Oliveira Niero & Liu Expires 5 May 2027 [Page 35] Internet-Draft DTR November 2026 * Parameter usage location: authorization request, token request * Change Controller: IETF * Specification Document(s): this specification * Parameter name: interaction_uri * Parameter usage location: token response * Change Controller: IETF * Specification Document(s): this specification The value of completion_mode is a space-separated list of values registered in the "OAuth Completion Mode Values" registry defined below. 13.2. OAuth Completion Mode Values Registry This specification requests the creation of a new IANA registry titled "OAuth Completion Mode Values" to hold the values that may appear in the space-separated completion_mode request parameter. The registry follows the "Specification Required" registration policy [RFC8126]. Each registration comprises: * Value: the completion-mode value (a single token containing no spaces). * Description: a brief description of the value's meaning. * Change Controller: for values registered by the IETF, "IETF"; otherwise the registering party. * Specification Document(s): a reference to the document defining the value. This specification registers the following initial values: * Value: deferred * Description: The client accepts a deferred response (Section 6.4) in place of an immediate token response or error. * Change Controller: IETF * Specification Document(s): this specification de Oliveira Niero & Liu Expires 5 May 2027 [Page 36] Internet-Draft DTR November 2026 * Value: deferred_interactive * Description: The client accepts a deferred response (Section 6.4) and is able to surface an interaction to the user or other external actor when the authorization server responds with interaction_required. * Change Controller: IETF * Specification Document(s): this specification 13.3. OAuth Dynamic Client Registration Metadata Registration This specification requests registration of the following client metadata definition in the IANA "OAuth Dynamic Client Registration Metadata" registry [RFC7591]: * Client Metadata Name: deferred_client_notification_endpoint * Client Metadata Description: HTTPS URL to which the authorization server sends a notification when a deferred authorization request resolves. * Change Controller: IETF * Specification Document(s): this specification 13.4. OAuth Grant Type Registry This specification requests registration of the following grant type in the IANA "OAuth Grant Type" registry, used as the value of the grant_type parameter on polling token endpoint requests (Section 6.5): * Name: urn:ietf:params:oauth:grant-type:deferred * Description: Polling grant type used to retrieve the eventual token response for a deferred authorization request, identified by a deferral code issued in a deferred response per Section 6.4. * Change Controller: IETF * Specification Document(s): this specification de Oliveira Niero & Liu Expires 5 May 2027 [Page 37] Internet-Draft DTR November 2026 13.5. OAuth Authorization Server Metadata Registry This specification requests registration of the following metadata parameters in the IANA "OAuth Authorization Server Metadata" registry defined in [RFC8414]: * Metadata Name: deferred_token_response_supported * Metadata Description: Boolean. If true, the authorization server supports the deferred token response defined in this specification. * Change Controller: IETF * Specification Document(s): this specification * Metadata Name: revocation_endpoint_token_type_values_supported * Metadata Description: JSON array of token type URIs accepted by the authorization server's revocation endpoint (revocation_endpoint) as values of the token_type_hint parameter. * Change Controller: IETF * Specification Document(s): this specification 13.6. OAuth URI Registration This specification requests registration of the following URIs in the IANA "OAuth URI" registry: * URI: urn:ietf:params:oauth:token-type:deferral-code * Common Name: Deferral Code * Change Controller: IETF * Specification Document(s): this specification * URI: urn:ietf:params:oauth:grant-type:deferred * Common Name: Deferred Token Response Polling Grant * Change Controller: IETF * Specification Document(s): this specification de Oliveira Niero & Liu Expires 5 May 2027 [Page 38] Internet-Draft DTR November 2026 13.7. OAuth Extensions Error Registry This specification updates the existing interaction_required registration in the IANA "OAuth Extensions Error Registry" defined by [RFC6749]. That error name was originally registered by [OIDC-CORE] for authorization endpoint use. This specification adds token endpoint response usage for the deferred-pending state defined in Section 6.6. * Error name: interaction_required * Error usage location: authorization endpoint response, token endpoint response * Related protocol extension: OpenID Connect; deferred token response * Change controller: OpenID Foundation Artifact Binding Working Group; IETF for token endpoint response usage defined by this specification * Specification document(s): OpenID Connect Core 1.0; this specification This specification also registers a new error code: * Error name: interaction_pending * Error usage location: token endpoint response * Related protocol extension: deferred token response * Change controller: IETF * Specification document(s): this specification 14. References 14.1. Normative References [OAUTH-2.1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet- Draft, draft-ietf-oauth-v2-1-17, 30 October 2026, . de Oliveira Niero & Liu Expires 5 May 2027 [Page 39] Internet-Draft DTR November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, . [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, . de Oliveira Niero & Liu Expires 5 May 2027 [Page 40] Internet-Draft DTR November 2026 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, . [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, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . 14.2. Informative References [CIBA] Rodriguez, G. F., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", 1 September 2021, . [FIPA] Parecki, A., Fletcher, G., and P. Kasselman, "OAuth 2.0 for First-Party Applications", Work in Progress, Internet- Draft, draft-ietf-oauth-first-party-apps-04, 1 July 2026, . [ID-JAG] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-06, 30 October 2026, . de Oliveira Niero & Liu Expires 5 May 2027 [Page 41] Internet-Draft DTR November 2026 [OIDC-CORE] "OpenID Connect Core 1.0", n.d., . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . Appendix A. Use Cases This section is informative. A.1. High-Risk Transaction Evaluation An online banking application requires the user to authorize a high- risk transaction — for example, a large outbound transfer to a new payee. It is acceptable for the authorization to take from several minutes to a few hours, because the transfer can settle out of band; the user does not need to remain engaged with the application during that time. When the user initiates the transaction, the banking application sends an authorization request to the bank's authorization server with completion_mode=deferred. The authorization server's risk- analysis system flags the transaction for additional review. The authorization server returns a deferred response carrying a deferral code. The bank performs additional verification — contacting the user through alternative channels, performing manual review by a fraud analyst, or applying other risk controls. During this time the user is free to close the banking application; on the next session, the client polls the token endpoint with the deferral code and renders the result of the transaction. If the bank registered a callback endpoint, it receives a notification when the result is committed and prompts the user proactively. de Oliveira Niero & Liu Expires 5 May 2027 [Page 42] Internet-Draft DTR November 2026 A.2. Step-Up Assurance During an In-Session Operation A user who signed in earlier with a low-assurance method (a stored password, for example) attempts an in-session operation that requires higher assurance — applying for a loan, changing contact details, or unlocking a sensitive feature. The authorization server needs to step up the user's assurance before issuing the token; the step-up may involve biometric verification or document presentation that is not guaranteed to complete instantly. The client sends an authorization request with completion_mode=deferred. The authorization server determines that the requested operation requires step-up, collects the relevant information from the user, returns a deferred response, and proceeds with the verification asynchronously. The client renders any unblocked steps of the user's workflow (form fill, preview, draft persistence) while polling for the eventual token response. This avoids forcing the user to wait on a single blocking screen during a verification that may legitimately take hours. A.3. Identity Verification Based on Physical Evidence In jurisdictions without widely deployed digital identity, a common identity-verification flow scans a physical document — a passport or driver's license — supplemented by a liveness check (a short video of the end-user matched against the photograph on the document). Most such verifications can be decided automatically. Some require a human operator to inspect the evidence, and that review can take hours. Regulation on automated decision-making in identity verification often makes the human-in-the-loop case mandatory rather than optional. The client sends the originating grant's token request with completion_mode=deferred. When automated verification suffices, the authorization server completes synchronously. When it does not, the authorization server returns a deferred response, queues the evidence for human review, and notifies the client when the review completes. The client UX continues immediately for users in the automated path and degrades gracefully — to "we are reviewing your documents, you will be notified" — for users in the deferred path, without requiring two separate authorization flows. de Oliveira Niero & Liu Expires 5 May 2027 [Page 43] Internet-Draft DTR November 2026 A.4. Autonomous Agent Acting on Behalf of a User An autonomous agent operates on behalf of a human principal under a narrow set of pre-approved scopes. The agent encounters a task that requires authorization beyond what was provisioned at enrollment — for example, executing a purchase above the per-transaction ceiling the principal granted. The agent sends a token request to the authorization server with completion_mode=deferred. The authorization server, recognizing that the requested scope exceeds standing approval, contacts the human principal out of band — by mobile push, email, or a separate approval application — and returns a deferred response to the agent. The agent suspends the affected task and continues with other work. When the principal approves (or denies) the request out of band, the authorization server resolves the deferred request; the agent retrieves the result by polling and either completes the task or terminates it cleanly. This pattern allows the principal to retain effective oversight without being on the synchronous path of every elevated request. A.5. Enterprise Identity Governance Approval A workforce client requests an access token whose scope corresponds to a sensitive resource — production database access, financial system administration, or PII export — that the enterprise gates through an Identity Governance and Administration (IGA) workflow. The workflow may involve approvals from the requestor's manager, the resource owner, and a security reviewer, and may take from several hours to several business days. The client sends a token request with completion_mode=deferred. The authorization server, recognizing that the requested scope is under IGA control, opens a request in the governance system, returns a deferred response, and notifies the relevant approvers through their normal channels. The client polls the token endpoint and surfaces the request as "pending approval" to the requesting user. As approvers act, the governance system records its decision; on final approval, the authorization server resolves the deferred request and the polling client receives the access token. On rejection or timeout, polling returns access_denied and the client clears the pending state. This pattern lets the authorization server remain the authoritative issuer of access tokens even when the decision logic lives in a purpose-built governance system, without requiring the client to integrate with the governance system directly. de Oliveira Niero & Liu Expires 5 May 2027 [Page 44] Internet-Draft DTR November 2026 A.6. AI Agent with Browser Access An AI agent acts on behalf of a user at a third-party service. The agent and the service both use the user's identity provider for sign- on. The agent first performs Token Exchange ([RFC8693]) with the identity provider and receives an identity assertion for the user. The agent then presents the assertion in the token request of the Identity Assertion JWT Authorization Grant ([ID-JAG]) at the service's authorization server. No user interaction has taken place at the service. The service requires the user's consent for the requested operation, and the assertion alone does not provide it. The grants that capture human consent today do not fit this request: the authorization code grant would require a redirect-based flow at the client, and CIBA would be a separate client-initiated request that cannot carry the assertion (Section 10.1). The agent sends the token request with completion_mode=deferred. The authorization server returns a deferred response, and polling returns interaction_required with an interaction_uri. The agent redirects the user's browser to the interaction_uri, and the user consents there. The consent is recorded together with the assertion, so the approval is linked to it: this agent, this user, this operation. The agent learns of the result by polling with the deferral code, or through a callback notification. A.7. Regulatory Compliance A user asks their AI assistant to gather the user's sensitive records from a third-party service. Privacy regulation requires the service to obtain the user's explicit consent before disclosing personal data to a third party, and to keep a record of what was approved and under which delegation it was requested. As in the previous use case, the agent and the service both use the user's identity provider for sign-on. The agent first obtains an identity assertion for the user through Token Exchange ([RFC8693]) and presents it in the token request. The assertion proves who the agent is and whom it acts for, but it is not the consent the regulation requires. de Oliveira Niero & Liu Expires 5 May 2027 [Page 45] Internet-Draft DTR November 2026 The agent sends the token request with completion_mode=deferred. The authorization server returns a deferred response, and polling returns interaction_required with an interaction_uri. The user consents at that URI. The authorization server records the consent together with the assertion, resolves the deferred request, and issues the token only after the interaction completes. The consent record and the assertion together show which delegation requested the access and that the user approved it. A.8. Interactive and Explicit Consent for Sensitive Operations A user asks their AI agent to pay a large invoice on their behalf. The payment service requires the user's explicit consent for high- value transactions: before issuing a token, it must show the user the amount and the recipient, and record the user's decision. As in the previous use cases, the agent and the service both use the user's identity provider for sign-on. The agent first obtains an identity assertion for the user through Token Exchange ([RFC8693]) and presents it in the token request. The assertion does not cover this specific transaction. The agent sends the token request with completion_mode=deferred. The authorization server returns a deferred response, and polling returns interaction_required with an interaction_uri. The agent opens the interaction_uri in the browser. The user sees the transaction and the delegation under which it was requested, and grants or declines consent there. The authorization server resolves the deferred request, and the agent retrieves the result by polling. If the user declines, polling returns access_denied and the agent terminates the task. Document History _[[ To be removed by the RFC Editor before publication as an RFC. ]]_ -01 * Merged with draft-parecki-oauth-jwt-grant-interaction-response. * Clarified behavior around publishing of deferred_token_response_supported in AS metadata. * Clarified behavior around treatment of completion_mode when AS does not support it. de Oliveira Niero & Liu Expires 5 May 2027 [Page 46] Internet-Draft DTR November 2026 * Expanded the sender-constraint rationale to distinguish sender- constraining as defense-in-depth for confidential clients from sender-constraining as the primary defense for public clients. * Reframed the sensitivity of a deferral code in terms of equivalence to a refresh token rather than to a bearer token. -00 * Initial version. Acknowledgments The authors would like to thank the following people for their contributions and reviews of this specification: Karl McGuinness, Mikkel Christensen, Mick Hansen, Vitor Watanabe, Ricardo Pereira Contributors The following individuals are co-authors: Frederik Krogsdal Jacobsen Idura frederik.krogsdal@idura.eu Maxwell Gerber Twilio mgerber@twilio.com Aaron Parecki Okta aaron@parecki.com Brian Campbell Ping Identity bcampbell@pingidentity.com Authors' Addresses Guilherme de Oliveira Niero (editor) Itaú Email: guilherme.niero@itau-unibanco.com.br Dapeng Liu (editor) Alibaba Group Email: max.ldp@alibaba-inc.com de Oliveira Niero & Liu Expires 5 May 2027 [Page 47]