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 <[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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
