[OAUTH-WG] Re: Feedback Requested: Deferred Token Response

[Max Gerber <[e-mail]>]

Yaron, Jeff,

Thank you for your comments. It's good to hear that the core problem
(asynchronous authorization decisions) resonates.

> deferral_code is used by the client as a CIBA login hint.

Reusing existing CIBA rails is a very interesting suggestion. I had two
problems applying CIBA to HITL usecases:
- CIBA is client-initiated, meaning that an authorization server cannot
easily direct a client to start a CIBA flow based on the result of a policy
decision, risk engine, etc.
- Today, the client identifies the user who must be contacted during CIBA,
which doesn't work well when the client doesn't know the user's identity or
when the access request must be routed dynamically.

Using an authorization-server-issued deferral_code as the CIBA login hint
fixes both of these issues. The authorization server instructs the client
when to initiate CIBA (by providing the hint). The authorization server
also reserves the right to determine where to route the request by keeping
the structure of the deferral_code opaque.

My chief concern is CIBA's* focus on end user authentication*, rather than
authorization. I believe CIBA requires the client to request the `openid`
scope and the authorization server to return an `id_token`, which may not
have semantic meaning for authorization servers that are not also openid
providers. CIBA parameters, such as binding messages and user codes, may
not make sense in this scenario either.

@Guilherme Niero <[e-mail]> @Frederik Krogsdal Jacobsen
<[e-mail]> - would love to hear your thoughts on this.

> Ithe deferral_code should be returned already from the authorization
endpoint.

Yes, our intent was to treat the Token endpoint as the common denominator
and define DTR for all grant types simultaneously. Returning the
deferral_code from the authorization endpoint would require defining DTR
behavior for the authorization code grant type separately, and possibly for
first-party apps as well.

Additionally, deferral codes are rather long-lived compared to
authorization codes. Returning them from the Token endpoint makes it
possible to apply DPoP binding to them, as described in §10.1. Returning
deferral codes from the authorization endpoint would break this property
(though, if we only use the deferral code as a CIBA login hint we could
apply DPoP to the CIBA auth_req_id instead...)

If the consensus is that it would be better to return the `deferral_code`
as soon as possible and avoid the awkwardness of issuing an authorization
code for a grant that has not completed + extra round trip call to the
Token endpoint that is something we can look into. @Karl McGuinness
<[e-mail]> has already opened an issue along those lines here
<https://github.com/maxwellgerber/deferred-token-response/issues/46>.

Thanks,
Max


On Tue, Jun 23, 2026 at 2:09 PM Lombardo, Jeff <jeffsec=
[e-mail]> wrote:

> Hi,
>
> This proposal seems to be interesting when AS-Backend access control
> decision needs more time to converge. It seems you put on the Token request
> cause it is the common denominator of all the grant flow, but by doing so
> it seems then that the deferred issuance is not related to Resource Owner /
> Subject related decision.
>
> Therefore, I got similar reaction as Yaron, In Authorization Code grant
> flow, the issuance of the authorization code would have already been
> performed. If all the controls related to this request are OK (scope,
> audience, Authorization details), delaying more at the token request feels
> bizarre. I second that in this case, the deferral_code should be returned
> already from the authorization endpoint.
>
>
>
> Jeff
>
>
>
> *Jean-François “Jeff” Lombardo* | Amazon Web Services
>
>
>
> Architecte Principal de Solutions, Stratégie de Sécurité
> Principal Solution Architect, Security Strategy
> Montréal, Canada
>
> *Commentaires à propos de notre échange? **Exprimez-vous **ici*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *Thoughts on our interaction? Provide feedback **here*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *From:* Yaron ZEHAVI <yaron.zehavi=[e-mail]>
> *Sent:* June 23, 2026 4:50 PM
> *To:* Max Gerber <mgerber=[e-mail]>; [e-mail]
> *Subject:* [EXT] [OAUTH-WG] Re: Feedback Requested: Deferred Token
> Response
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur
> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous
> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas
> certain que le contenu ne présente aucun risque.
>
>
>
> Dear Max and colleagues,
>
> The proposal is interesting and I agree with your reasoning regarding
> authorization servers which may need to decide to divert various grant
> flows to asynchronous and possibly multi-party interactions.
>
>
>
> However, since CIBA, which you identify as providing some of the desired
> capabilities, already solves polling / push notification mechanisms –
> perhaps the gap can be bridged without building so much from scratch?
>
> Imagine this high-level flow:
>
>    1. The client initiates whatever grant.
>    2. Authorization server decides on asynchronous interaction and
>    returns a deferral_code. I assume this point is reached after some
>    information is provided and in redirect flows also user interaction, so
>    authorization server can determine who the user(s) are, how to contact them
>    etc.
>    3. deferral_code is used by the client as a CIBA login hint.
>
>
>
> Another note – perhaps in authorization code oauth flows, the
> deferral_code should be returned already from the authorization endpoint.
>
>
>
> Regards,
>
> Yaron
>
>
>
>
>
>
>
> Classification: GENERAL
>
> *From:* Max Gerber <mgerber=[e-mail]>
> *Sent:* Tuesday, June 23, 2026 3:57 PM
> *To:* [e-mail]
> *Subject:* [OAUTH-WG] Feedback Requested: Deferred Token Response
>
>
>
> You don't often get email from mgerber=[e-mail]. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> This message is from an external sender - be cautious, particularly with
> links and attachments.
>
>
>
> Dear OAuth Working Group,
>
>
>
> We would like to request your opinions on this draft:
> https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/
>
>
>
> This document proposes an opt-in mechanism to convert OAuth grants into
> asynchronous processes - extracting the polling and notification mechanisms
> defined in device authorization and CIBA grants into a generic mechanism
> that can be applied to any grant type.
>
>
>
> This asynchronous deferral mechanism empowers the authorization server to
> deal with authorization decisions that 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.
>
>
>
> Slides comparing this draft to CIBA, specifically for human-in-the-loop
> cases for AI Authorization can be found here
> <https://maxgerber.com/slides/ciba-vs-dtr-may-2026.html>.
>
>
>
> This recent IETF draft evolved from an earlier draft
> <https://github.com/gniero/oidc-dtr-resources/tree/main> of the same name
> in the OIDF after we realized the proposed mechanism was suitable for a
> wider range of use cases. Additionally, the draft seeks interoperability
> with the AuthZEN Access Request and Approval Profile Draft
> <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html>,
> which adds an asynchronous requesting flow to AuthZEN systems as well.
>
>
>
> The draft was presented recently at IIW #42. Both Frederik and Max will be
> present for IETF 126 and are hoping for feedback from the working group.
>
>
>
> Thank you,
>
>
>
> Frederik, Guilherme, and Max
>
>
>
>
>
>
> This message and any attachment ("the Message") are confidential. If you
> have received the Message in error, please notify the sender immediately
> and delete the Message from your system, any use of the Message is
> forbidden. Correspondence via e-mail is primarily for information purposes.
> RBI neither makes nor accepts legally binding statements via e-mail unless
> explicitly agreed otherwise. Information pursuant to § 14 Austrian
> Companies Code: Raiffeisen Bank International AG; Registered Office: Am
> Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at
> the Commercial Court of Vienna (Handelsgericht Wien).
>