Then the sentence should not open extension points even for confidential clients, - by mention OIDC notice explicitly - by allowing currently existing alternatives only (and prohibit new ones) etc.
iPadから送信 > 2020/05/15 8:36、Aaron Parecki <aa...@parecki.com>のメール: > > >> 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
