Hi Jeff, Thanks for the feedback, which, as I understand it, can be summarized as follows: DTR defines a flow that starts with one grant type and is finalized with another, which is not currently an established pattern in the OAuth framework.
I basically agree with this characterization. DTR applies deferral to an arbitrary originating grant, keeps the flow pending, and resolves it at the token endpoint with the deferred code. As far as I know, there is no other OAuth spec that supports this exact pattern, which is why we are proposing this. I know of three similar patterns from which we can derive inspiration. I will try to explain my thoughts on why DTR does not quite fit into either of these (if I've missed something please let me know). 1. Special-purpose grant type This is what CIBA and RFC 8628 do. The difference to DTR is that CIBA and RFC 8628 both only support exactly one grant type. Defining DTR this way would mean specifying initiation for every originating grant, which removes the ability to use it for any grant. 2. Chaining one grant's output into another This is what refresh tokens and RFC 8693 do. This only works if the original grant completes and yields a usable credential. The pending state (where the deferral code is issued) in DTR does not mean that authorization has completed, so this pattern does not really apply. 3. New continuation endpoint This is what RFC 9635, OpenID4VCI deferred issuance and ARAP do. This keeps continuation separate from grant type, so the mechanism stays grant-agnostic without defining a new grant type. But it moves resolution off the token endpoint and requires a separate continuation endpoint instead of reusing the token endpoint. Rifaat requested in a separate thread that presentations at IETF 126 should focus on problem statement and gaps. As we talk to more people about deferral, I keep seeing more use cases pop up. I think there is a real gap in the OAuth framework here that is worth discussing, even if DTR is not the solution that reaches consensus. Cheers, Frederik On Thu, 25 Jun 2026 at 14:56, Lombardo, Jeff <jeffsec= [email protected]> wrote: > With this piece of feedback it seems to point more and more than this is a > need for a new grant type more than just a response code and polling. I > second the need for negotiation between parties: Client / AS, Client /RS. > > > > Now this raises an important question if so: can I start an authorization > request using a Grant A and finalize it with a Grant B against the same AS? > > > > Jeff > > > > *From:* Karl McGuinness <[email protected]> > *Sent:* June 24, 2026 10:04 PM > *To:* Guilherme Oliveira Niero <guilherme.niero= > [email protected]> > *Cc:* [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. > > > > Thanks Guilherme, that's a useful framing. > > Agreed on the token-endpoint convergence rationale. Anchoring deferral at > the token endpoint keeps the substrate grant-agnostic and avoids forking > the wire shape per originating flow. That's the right call. > > On the PAR requirement for sender-constraining public clients in direct > authorization-endpoint deferral: I don't think PAR is strictly necessary as > a precondition. The symmetry holds with the standard authorization_code > flow*:* a public client sends code_challenge on the front-channel > request, then proves possession with code_verifier on the back-channel > token exchange. For direct deferral, the same shape works if the AS treats > the first polling request as the binding point for PKCE: the front-channel > request carries code_challenge, and the client supplies code_verifier on > its first poll. The deferral code remains sender-constrained to the holder > of the verifier without requiring PAR. PAR is still valuable for > request-object integrity and avoiding URL-length limits, but it isn't > load-bearing for sender-constraining alone. I filed > maxwellgerber/deferred-token-response#46 > <https://github.com/maxwellgerber/deferred-token-response/issues/46> and > PR #47 <https://github.com/maxwellgerber/deferred-token-response/pull/47> > sketching > this as an optional extension; the default (token-endpoint-only deferral) > is unchanged. > > Hint-only and direct deferral can coexist as different defaults. Hint-only > keeps the substrate minimal and is the right default for grants where the > authorization endpoint isn't involved (client_credentials, token_exchange, > refresh_token). Direct deferral is opt-in via AS metadata and only relevant > for front-channel flows where the AS already knows at authorization time > that completion will be asynchronous. > > CIBA reuse: agreed. The structural mismatch is CIBA's presumption that an > end-user is already identified to the OP and is initiating an > authentication transaction; DTR applies to any OAuth grant > (client_credentials, token_exchange, refresh_token, authorization_code, > jwt-bearer) without that presumption. Worth noting that DTR already borrows > from CIBA where it makes sense: client_notification_token adopts the > client-issued direction, which I think is the right call. An AS supporting > both can use CIBA for end-user-initiated backchannel auth and DTR for any > other deferral, with the notification model effectively shared. > > One more data point on the substrate framing: I've drafted an AuthZEN > Access Request OAuth Profile (openid/authzen#531 > <https://github.com/openid/authzen/pull/531>) that composes DTR with RAR > and the AuthZEN Access Request and Approval Profile (ARAP > <https://github.com/openid/authzen>) for AuthZEN-driven access requests. > It treats DTR as the deferred-transport substrate without introducing a new > grant type or parameter. This is a useful sanity check that the > substrate-shape positioning works for at least one external profile. > > -Karl > > > > On Wed, Jun 24, 2026 at 11:48 AM Guilherme Oliveira Niero > <[email protected]> wrote: > > Hi all, > > > > Thank you for the feedback so far. > > > > Making the token endpoint the point at which deferral happens was the path > we found to converge most grant types without having to introduce per-grant > changes. > > In our first proposal (drafted as an OIDC extension) we ended up defining > a new response type, but it still couldn't eliminate the intermediary hop > deferred_code -> deferred_auth_req_id. Beyond that, there is one thing that > approach cannot cover: if the AS needs to defer for a non-identity-related > reason, that signal must be raised during the user interaction. > > > > In a non-deferred flow, a response carrying a code means the end-user > interaction completed and authorization was granted. When authorization is > requested with deferral, the presence of a code only signals that the user > interaction happened as expected; the actual outcome is only known at token > retrieval. > > > > > perhaps in authorization code OAuth flows, the deferral code should be > returned already from the authorization endpoint. > > > > That would be more straightforward to implement, but I can't see a clean > way to sender-constrain the deferred code when a public client requests it. > We would likely need an arrangement with PAR to make that workable. > > > > On the similarities with CIBA, I agree with Max: OpenID Connect's > specificities could end up mismatching the OAuth framework if we were to > reuse its endpoints and/or attributes. > > > > I wanted to share these points to explain some of the rationale behind the > current approach, but I'm really interested in hearing more thoughts and > suggestions that help us make it tidier. > > > > Regards, > > Guilherme > > > > Corporativo | Interno > > Esta mensagem é reservada e sua divulgação, distribuição, reprodução ou > qualquer forma de uso é proibida e depende de prévia autorização desta > instituição. O remetente utiliza o correio eletrônico no exercício do seu > trabalho ou em razão dele, eximindo esta instituição de qualquer > responsabilidade por utilização indevida. Se você recebeu esta mensagem por > engano, favor eliminá-la imediatamente. > > This message is reserved and its disclosure, distribution, reproduction or > any other form of use is prohibited and shall depend upon previous proper > authorization. The sender uses the electronic mail in the exercise of > his/her work or by virtue thereof, and the institution takes no liability > for its undue use. If you have received this e-mail by mistake, please > delete it immediately. > > _______________________________________________ > 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]
