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 <[email protected]> Sent: June 23, 2026 4:50 PM To: Max Gerber <[email protected]>; [email protected] 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 <[email protected]<mailto:[email protected]>> Sent: Tuesday, June 23, 2026 3:57 PM To: [email protected]<mailto:[email protected]> Subject: [OAUTH-WG] Feedback Requested: Deferred Token Response You don't often get email from [email protected]<mailto:[email protected]>. 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).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
