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]
