Shankar, Thank you for the thorough and detailed comments.
First, restating some of the motivations behind DTR: - DTR is not the first asynchronous approval mechanism to be tried at the OAuth token endpoint. OpenID's CIBA and OAuth's Device Authorization Grant both feature polling and asynchronous approval mechanisms. However, both of those methods are tied to a specific grant and are not generally applicable. - A lack of a general asynchronous approval mechanism has led to ecosystems built on top of OAuth to take matters into their own hands. For example OpenID4VCI <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-09.html#name-successful-token-response> includes a bespoke polling mechanism. The MCP community built URL Elicitation <https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation> . - Multiple efforts to replace or augment OAuth have added asynchronous approval mechanisms. GNAP <https://www.rfc-editor.org/info/rfc9635/#section-1.6.4> features asynchronous authorization. AAuth supports both polling <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11#name-deferred-delivery> and interaction <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11#name-interaction-required> based resolution mechanisms. DTR is an effort to promote some of these already-existing asynchronous methods to first-class citizens in OAuth, so that we can use these methods without needing to move to new protocols entirely. The goal is to surgically implant this functionality in a backwards-compatible opt-in way, which can be rolled out to existing ecosystems. *> Section 1 states that existing OAuth grants leave clients without a* *> mechanism to handle asynchronous authorization decisions. ...* *> In our production systems, we handle many of these scenarios* *> through a centralized risk and enforcement layer:* *> - a) Services evaluate risk when sensitive operations are requested.* *> - b) The enforcement layer returns allow, deny, or challenge.* *> - c) Clients complete interactive challenges or receive a pending* *status for longer reviews.* * > - d) The application resumes the operation once the required* *checks are complete.* Yes, I agree that many of these things can be (and are!) done at the application layer. I am sure hundreds of internal approval mechanisms and application-level workflows have been developed at companies over the last decade+; I have built one or two myself. These internal enforcement systems grew out of necessity, but I don't believe they represent an ideal state. They often are not interoperable and push authorization responsibility onto the resource server. What makes an operation sensitive? When are approvals required? Who should review each approval? Those are questions the authorization server should be answering, but we are unable to do so today. Application-level workflow models work inside one organization with a centralized enforcement layer that every service integrates with. They don’t work well with third-party clients or agents from another trust domain. With DTR, we hope to give those clients a standard way to interact with the system. *> 2. Why should deferred business decisions be tied to token issuance?* *> (Sections 9.5, 12.2)* *> Fraud reviews, identity verification, and governance approvals often* *> depend on multiple external systems. These systems have different* *> failure modes, retry policies, and data-retention requirements. One* *> important design principle we have followed is to keep these workflows* *> separate from token issuance. This allows teams to change risk rules,* *> verification providers, and approval processes independently of the* *> authorization infrastructure. * I would argue the opposite. I want my authorization server to isolate and abstract away as much of the fraud, risk, identity, and governance parts of the ecosystem as it can. If we change from one ID verification provider to another, or one IGA vendor to another, I want to be able to do so without needing to touch a single resource server, because the AS can keep all of that complexity within its boundaries. *> - a) Who owns recovery when an external workflow fails or requires* *> resubmission?* *> - b) How should partial results, retries, and workflow expiration* *> affect the pending token request?* *> - c) How can implementations keep sensitive verification data and* *> business workflow state separate from the AS?* DTR says nothing about how an Authorization Server should come to a verdict on a response. External workflows, partial results, retries, etc. are all implementation details subject to a specific AS. I do not believe we need any normative text or recommendation to that effect. *> Section 11.7 addresses whether existing consent remains valid.* *> Appendix A.6–A.8 also describe collecting new consent through* *> interaction_uri. These are different requirements. OAuth* *> authorization, consent to process sensitive personal data, and* *> acceptance of contractual terms may require different interactions and* *> evidence. DTR provides a way to initiate an interaction, but the draft* *> should clarify that this mechanism alone does not establish whether* *> the resulting agreement is valid or sufficient. * DTR provides a way for the AS to request user interaction; it says nothing about whether that interaction satisfies legal, regulatory, or contractual consent requirements. IMO that determination is outside the scope of OAuth generally (and of this draft). *> I'm also concerned* *> about phishing and consent laundering when an agent requesting* *> additional privileges directs a user to an interaction_uri. Although* *> the draft includes URI binding and replay protections, it should* *> explain how users can independently verify the requesting client,* *> authorization server, requested permissions, and transaction details* *> before approving.* I think the user’s ability to verify the client, the AS, and the requested access there is the same as for the regular OAuth authorization endpoint. I am interested in any text you might want to see added to the security considerations to make this clearer. *> Although DTR is opt-in, implementing it introduces several new* *> protocol elements:* *> a) Deferred state across existing grants.* *> b) A new polling grant and long-lived deferral credentials.* *> c) Cancellation and revocation semantics.* *> d) Optional callbacks and additional completion states.* *> These features must also work with existing OAuth extensions,* *> including DPoP, mTLS, PAR, JAR, RAR, and Token Exchange. What* *> interoperability benefit requires defining DTR as a general-purpose* *> mechanism rather than a narrower extension for the specific grants* *> that need it? If the strongest unmet requirements arise from specific* *> assertion-based grants, would a more focused profile be sufficient?* I agree that DTR has grown to cover a large scope. Our goal was to introduce a general-purpose mechanism instead of specific profiles because we believed there would be many, many profiles. Introducing new asynchronous or interactive versions of each grant would double or triple the number of OAuth grants. JAG-IR started as a specific profile of assertion-based grants, and the community reception in Vienna was that the profile should be merged into DTR. I believe the existing draft addresses interoperability with DPoP, PAR, JAR, RAR, and many other OAuth extensions. If there are interactions that you feel are underspecified, please let us know and we will try to remediate them. *> - a) Deferral codes (Section 11.1): The draft recognizes their* *> refresh-token-like sensitivity, but DPoP is not mandatory for all* *> confidential clients. Could the authors clarify when client* *> authentication alone provides sufficient protection?* RFC9449 <https://datatracker.ietf.org/doc/html/rfc9449#section-5-11> does not require DPoP to be used with refresh tokens issued to confidential clients. We adopt an identical stance here. See §11.1 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-01#name-sender-constraint-requireme>: public clients MUST use DPoP, confidential clients using mTLS or private_key_jwt MAY rely on client authentication alone, and clients using shared-secret authentication SHOULD use DPoP. *> - b) HTTP error responses (Section 6.4): The initial deferred response* *> uses HTTP 400 while carrying a credential needed to continue the flow.* *> Existing SDKs and logging systems may discard or log these responses.* *> This compatibility risk deserves further consideration.* RFC 6749 requires a successful token response to include an access token, so returning a deferral with a 200 would risk breaking clients that treat success as token issuance. Using the standard error response format means clients unaware of DTR handle it through their existing error paths, and since a client only receives a deferred response after opting in, any client receiving a deferral code is one that knows to look for it. The draft already has text noting that deferral codes should be kept out of logs, and deferral codes should only ever be returned to clients who have opted in to the flow anyway. *> - c) Callbacks (Sections 7, 9.2): Callbacks introduce additional* *> security and operational complexity, yet the draft recommends* *> continued polling. Could callbacks be moved into a separate optional* *> profile?* This is an interesting suggestion. I am eager for ways to cut the scope and complexity of this draft, and this could be one option to pursue. What is your Github username? I can add you to any issues we open from these points. Best, Max On Mon, Nov 2, 2026 at 5:56 PM Shankar <[email protected]> wrote: > Hi all, > > I've reviewed draft-ietf-oauth-deferred-token-response-01. At this > point, I'm not convinced the draft establishes an interoperability gap > that justifies introducing a general-purpose deferred token response > mechanism across OAuth grants. Asynchronous approval and verification > workflows are real requirements, but it is not clear that they need to > be addressed at the OAuth token endpoint. I would like to better > understand what existing approaches cannot solve before introducing > additional protocol complexity. > > For context, I've designed and currently operate production systems > for fraud and risk evaluation, step-up authentication, identity > verification, and agent authorization. These systems enforce security > policies across hundreds of microservices owned by dozens of teams. > They support dozens of challenge and review workflows, including > document and liveness verification, additional authentication, and > manual fraud reviews. > > My concerns are primarily about the problem statement, architectural > boundaries, and scope of the proposal. > > 1. What interoperability gap does DTR address? (Section 1, Appendix A) > > Section 1 states that existing OAuth grants leave clients without a > mechanism to handle asynchronous authorization decisions. This is true > for continuing a pending token request, but not necessarily for the > underlying workflows. In our production systems, we handle many of > these scenarios through a centralized risk and enforcement layer: > - a) Services evaluate risk when sensitive operations are requested. > - b) The enforcement layer returns allow, deny, or challenge. > - c) Clients complete interactive challenges or receive a pending > status for longer reviews. > - d) The application resumes the operation once the required > checks are complete. > > Existing tokens remain valid for operations that are already > authorized. This approach also allows risk decisions to use the full > request context, including transaction details, device signals, and > user history. RFC 9470 already provides a mechanism for certain > step-up authentication challenges. Other verification and approval > workflows can be handled at the application layer. > > Could the authors explain, for each Appendix A use case, why existing > OAuth mechanisms or application-level workflows are insufficient? > > I recognize that this approach does not address every case. Appendix > A.6–A.8, where an agent requests authorization using an identity > assertion and user consent may be required before token issuance, > appear to present a stronger motivation for DTR. > > 2. Why should deferred business decisions be tied to token issuance? > (Sections 9.5, 12.2) > > Fraud reviews, identity verification, and governance approvals often > depend on multiple external systems. These systems have different > failure modes, retry policies, and data-retention requirements. One > important design principle we have followed is to keep these workflows > separate from token issuance. This allows teams to change risk rules, > verification providers, and approval processes independently of the > authorization infrastructure. DTR does not require the authorization > server (AS) to perform these workflows. However, it introduces > persistent pending-token state whose resolution depends on external > decisions. This raises several operational questions: > > - a) Who owns recovery when an external workflow fails or requires > resubmission? > - b) How should partial results, retries, and workflow expiration > affect the pending token request? > - c) How can implementations keep sensitive verification data and > business workflow state separate from the AS? > > Section 9.5 leaves external workflow integration out of scope, while > Section 12.2 excludes disposal of data collected during deferred > processing. I suggest documenting how implementations should separate > the responsibility for token issuance from the systems performing > verification and approval. > > 3. Why is a grant-agnostic extension necessary? (Sections 4–8) > > Although DTR is opt-in, implementing it introduces several new > protocol elements: > > a) Deferred state across existing grants. > b) A new polling grant and long-lived deferral credentials. > c) Cancellation and revocation semantics. > d) Optional callbacks and additional completion states. > > These features must also work with existing OAuth extensions, > including DPoP, mTLS, PAR, JAR, RAR, and Token Exchange. What > interoperability benefit requires defining DTR as a general-purpose > mechanism rather than a narrower extension for the specific grants > that need it? If the strongest unmet requirements arise from specific > assertion-based grants, would a more focused profile be sufficient? > > 4. Consent and interaction security (Sections 6.4, 11.7) > > Section 11.7 addresses whether existing consent remains valid. > Appendix A.6–A.8 also describe collecting new consent through > interaction_uri. These are different requirements. OAuth > authorization, consent to process sensitive personal data, and > acceptance of contractual terms may require different interactions and > evidence. DTR provides a way to initiate an interaction, but the draft > should clarify that this mechanism alone does not establish whether > the resulting agreement is valid or sufficient. I'm also concerned > about phishing and consent laundering when an agent requesting > additional privileges directs a user to an interaction_uri. Although > the draft includes URI binding and replay protections, it should > explain how users can independently verify the requesting client, > authorization server, requested permissions, and transaction details > before approving. > > 5. Additional protocol and security considerations > > - a) Deferral codes (Section 11.1): The draft recognizes their > refresh-token-like sensitivity, but DPoP is not mandatory for all > confidential clients. Could the authors clarify when client > authentication alone provides sufficient protection? > - b) HTTP error responses (Section 6.4): The initial deferred response > uses HTTP 400 while carrying a credential needed to continue the flow. > Existing SDKs and logging systems may discard or log these responses. > This compatibility risk deserves further consideration. > - c) Callbacks (Sections 7, 9.2): Callbacks introduce additional > security and operational complexity, yet the draft recommends > continued polling. Could callbacks be moved into a separate optional > profile? > > Suggested path forward > > Before progressing with DTR as a general-purpose OAuth extension, I > suggest: > - a) Mapping each Appendix A use case to existing mechanisms and > identifying the specific interoperability gaps. > - b) Clarifying the boundaries between token issuance and external > verification or approval workflows. > - c) Evaluating whether the remaining gaps justify a grant-agnostic > extension or a narrower solution. > - d) Addressing the security and interoperability questions above. > > My concern is not that asynchronous authorization workflows are > unnecessary, but that the need for this particular protocol > abstraction has not yet been demonstrated. > > In production, I've solved many of the risk, verification, and > approval scenarios described in Appendix A at scale by keeping these > workflows separate from token issuance. This allows us to introduce > new security controls without changing OAuth flows or individual > services. > > In comparison, DTR appears to introduce significant complexity and > operational coupling, raising concerns about reliability, scalability, > and maintainability. I would welcome concrete examples showing where > this approach falls short and why DTR is necessary. Happy to discuss > further. > > Regards, > Shankar > > > > On Mon, Nov 2, 2026 at 1:07 AM 刘大鹏(鹏成) > <[email protected]> wrote: > > > > Hi all, > > > > We have posted -01 of the Deferred Token Response draft: > > > https://www.ietf.org/archive/id/draft-ietf-oauth-deferred-token-response-01.html > > > > The main change in this version is that the integration with JAG-IR is > now nearly complete. > > > > The draft defines the interactive redirect flow: > > - The interaction_required state and the interaction_uri response > parameter (#49). > > - The interaction_pending error code (#68) and its IANA registration > (#77). > > - The deferred_interactive completion mode (#71). > > - The use cases covering the JAG-IR scenarios (#69). > > > > Other changes since -00: > > - Updated the Overview section to cover the interaction states (#74). > > - Added a reference to RFC 9126 (PAR) (#78). > > - Added implementation considerations on 128-bit entropy (#70). > > > > Remaining issue: > > #79: how redirect_uri should be handled in the JAG-IR flow. The PR adds > redirect_uri to the token request, so that, after the user completes the > interaction, the authorization server redirects the browser back to the > client as a completion signal only. > > The open question is: redirect_uri was originally designed for JAG-IR, > and extending it to other grant types (e.g., authorization_code, which > already has a redirect_uri) raises parameter compatibility issues that need > more thought. The PR is open and needs broader discussion at IETF 127. > > > > PRs referenced above: > > #49 https://github.com/oauth-wg/oauth-deferred-token-response/pull/49 > > #68 https://github.com/oauth-wg/oauth-deferred-token-response/pull/68 > > #69 https://github.com/oauth-wg/oauth-deferred-token-response/pull/69 > > #70 https://github.com/oauth-wg/oauth-deferred-token-response/pull/70 > > #71 https://github.com/oauth-wg/oauth-deferred-token-response/pull/71 > > #74 https://github.com/oauth-wg/oauth-deferred-token-response/pull/74 > > #77 https://github.com/oauth-wg/oauth-deferred-token-response/pull/77 > > #78 https://github.com/oauth-wg/oauth-deferred-token-response/pull/78 > > #79 https://github.com/oauth-wg/oauth-deferred-token-response/pull/79 > > > > Dapeng Liu > > > > ------------------------------------------------------------------ > > 发件人：<[email protected]> > > 日 期：2026年11月01日 00:12:17 > > 收件人：<[email protected]> > > 抄 送：<[email protected]> > > 主 题：[OAUTH-WG] I-D Action: > draft-ietf-oauth-deferred-token-response-01.txt > > > > Internet-Draft draft-ietf-oauth-deferred-token-response-01.txt is now > > available. It is a work item of the Web Authorization Protocol (OAUTH) > WG of > > the IETF. > > > > Title: Deferred Token Response > > Authors: Guilherme de Oliveira Niero > > Dapeng Liu > > Name: draft-ietf-oauth-deferred-token-response-01.txt > > Pages: 47 > > Dates: 2026-10-31 > > > > 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. > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token-response/ > > > > There is also an HTML version available at: > > > https://www.ietf.org/archive/id/draft-ietf-oauth-deferred-token-response-01.html > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-deferred-token-response-01 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > OAuth mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > OAuth mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
