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]>
Sent: Tuesday, June 23, 2026 3:57 PM
To: [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]

Reply via email to