Hi Max, Thank you for taking the time to respond so clearly and thoroughly, point by point. I appreciate your willingness to engage with my feedback. Your explanation of the motivation for DTR, particularly the desire for a grant-agnostic mechanism and the discussion in Vienna, helped me better understand the design decisions.
I have a few follow-up thoughts. >> DTR is an effort to promote some of these already-existing asynchronous >> methods to first-class citizens in OAuth. I understand the motivation for a common, opt-in mechanism that works across OAuth grants. However, I think we should distinguish asynchronous token issuance from asynchronous business workflows. The examples you cited demonstrate the need for asynchronous interactions, but not necessarily for deferring token issuance. For example, OpenID4VCI supports deferred credential issuance, while MCP URL Elicitation supports user interactions outside the OAuth token flow. These solve different problems. I agree that interoperability across trust domains is important. My remaining question is which scenarios specifically require deferring the token response rather than handling the asynchronous decision elsewhere. >> 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. I agree that third-party clients and agents need a consistent way to handle pending approvals and resume operations. However, the client-facing protocol and the architecture used to evaluate and enforce risk are separate concerns. In the approach I described, a resource server or gateway consults a dedicated Fraud/Risk Service and returns an operation-level challenge or pending response to the client. The Authorization Server remains independent of this workflow. I recognize that this approach still requires a well-defined client-facing contract, particularly across trust domains. My question is whether that requirement necessarily means the asynchronous decision should be handled through the OAuth token endpoint. >> 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. I agree with the goal of abstracting these integrations, but I believe that responsibility belongs in dedicated systems, not the Authorization Server. In our production architecture, a centralized Fraud/Risk Service evaluates requests and returns decisions such as allow, deny, or challenge. Resource servers can invoke it directly, or a gateway or sidecar can intercept requests and consult it, similar to Envoy's external authorization filter (ext_authz). This separation matters at scale. Fraud platforms can manage thousands of frequently changing rules, risk models, and external integrations. As a publicly documented example, Grab's Griffin fraud engine (https://engineering.grab.com/griffin) processes billions of predictions daily, at a scale comparable to fraud systems I have worked with. Authorization servers have their own complex OAuth flows, authorization logic, and partner integrations. Combining these responsibilities increases operational coupling and the potential blast radius. A fraud-rule deployment or verification-provider outage should not disrupt unrelated token issuance. Importantly, a client may already hold a valid access token, but a sensitive API operation can still require additional risk evaluation. For example, an authenticated user may attempt a high-value transaction from a device flagged as tampered, add an unfamiliar payment method, or perform a sensitive operation from an unusual location. These decisions can be evaluated by dedicated risk systems and enforced at the resource server or gateway, independently of token issuance. >> 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. Agreed. I was not suggesting that DTR should standardize external workflow management, retries, or data retention. My concern is the operational coupling that can arise when these workflows are coordinated through token issuance. I recognize that the draft leaves the implementation of external services out of scope. >> 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. Agreed. Determining whether an interaction establishes legally sufficient consent is outside the scope of DTR. My concern was that implementers should not mistake completion of an interaction for proof that all applicable consent requirements have been satisfied. >> I am interested in any text you might want to see added to the security >> considerations to make this clearer. Thank you. I would suggest adding guidance along these lines: "When an interaction_uri is used to obtain approval, the interaction handler needs to authenticate the approving party and verify that the party is authorized to approve the specific request. The resulting approval needs to be bound to the requesting client, requested permissions, and relevant transaction context." The draft already requires binding the interaction_uri to the deferral state and prevents URI access alone from completing authorization. The additional concern is ensuring that the correct party approves the correct request, particularly when the requesting client is an autonomous agent. >> Our goal was to introduce a general-purpose mechanism instead of specific >> profiles because we believed there would be many, many profiles. I understand this rationale, particularly given the feedback on JAG-IR in Vienna. A common mechanism is preferable to creating separate asynchronous variants of many OAuth grants. I do not have a specific unresolved interoperability issue involving DPoP, PAR, JAR, RAR, or Token Exchange at this point. My broader concern remains the scope of the mechanism and its intended use cases. >> RFC9449 does not require DPoP to be used with refresh tokens issued to >> confidential clients. We adopt an identical stance here. That clarification addresses my concern about sender constraints. Thank you. >> RFC6749 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. Agreed. I understand the rationale for HTTP 400, particularly given the explicit client opt-in. My concern about SDK and logging behavior is primarily an implementation consideration. >> 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. I appreciate your openness to separating callbacks into an optional profile. Given that polling remains the authoritative mechanism, I think this would be a useful simplification. One final suggestion on applicability: I recognize that DTR does not prescribe an internal architecture. However, even informative examples in standards can influence architectural decisions. The draft's high-risk transaction and step-up examples could suggest that asynchronous approvals generally belong in the token issuance flow. That is not always appropriate. As discussed above, a client may already have an access token while a sensitive resource operation requires additional risk evaluation or approval. DTR addresses a different problem: when the token request itself cannot yet be completed. Could the draft include a short "Applicability and Non-Goals" section that clarifies this distinction and describes resource-level enforcement as an alternative? This guidance is increasingly important as developers and AI coding agents use standards and their examples to guide implementations. Clear applicability boundaries would help prevent DTR from being used for workflows that do not require deferred token issuance. >> What is your Github username? I can add you to any issues we open from these >> points. My GitHub username is gbshankar. I would be happy to participate in any issues opened from this discussion. Thanks again for the thoughtful engagement and your willingness to consider these suggestions. Best, Shankar On Mon, Nov 2, 2026 at 8:56 PM Max Gerber <[email protected]> wrote: > > 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 includes a bespoke polling mechanism. The MCP community built URL > Elicitation. > > - Multiple efforts to replace or augment OAuth have added asynchronous > approval mechanisms. GNAP features asynchronous authorization. AAuth supports > both polling and interaction 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 does not require DPoP to be used with refresh tokens issued to > confidential clients. We adopt an identical stance here. See §11.1: 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]
