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 <guilherme.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]
