> > There is no specific mechanism right now. > But future developers won’t be able to read the reason why the extension > point is given only for confidential clients.
This is not a compelling argument. The current situation is that we know of a handful of threats and attacks, we know that PKCE solves them for both confidential and public clients, and we also believe that OpenID Connect has solved one of the threats for confidential clients a different way. The reason this conversation is happening at all is because we want to make sure that OpenID Connect can continue to solve that problem its own way outside of OAuth without conflicting with OAuth. It's not useful to anyone to leave extension points open for hypothetical solutions later when we already know of a solution that works for public clients. At that point that should just be a new spec. Aaron Parecki On Thu, May 14, 2020 at 3:18 AM Nov Matake <mat...@gmail.com> wrote: > There is no specific mechanism right now. > But future developers won’t be able to read the reason why the extension > point is given only for confidential clients. > > > On May 14, 2020, at 18:32, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > > > Are you aware of any suitable mechanism? I’m asking since from my > perspective this clause is mainly intended to allow existing OpenID Connect > deployments to use nonce instead of PKCE in combination with OAuth 2.1. > It’s a compromise. I think we should not encourage others to invent their > own OAuth security mechanisms. > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
