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]
