Yes, and also, many of those providers very likely already support PKCE already. Skimming through that list of certified OPs, I recognize many names there from providers that I know support PKCE.
On Wed, May 6, 2020 at 12:18 PM Steinar Noem <stei...@udelt.no> wrote: > So, wouldn't a MUST just mean that we would have some OPs that are 2.1 > compliant and some that aren't? > > ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt <phil.h...@independentid.com > >: > >> Mike, >> >> The point of 2.1 is to raise the security bar. >> >> Yes it adds new MUST requirements. >> >> But what about OIDC would break other than required implementation of >> PKCE to support 2.1? >> >> Eg Would additional signaling be required to facilitate interoperability >> and migration between versions? Would that be an oauth issue or an OIDC one? >> >> Phil >> >> On May 6, 2020, at 11:56 AM, Aaron Parecki <aa...@parecki.com> wrote: >> >> >> > In particular, authorization servers shouldn’t be required to support >> PKCE when they already support the OpenID Connect nonce. >> >> The Security BCP already requires that ASs support PKCE: >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 >> Are >> you suggesting that the Security BCP change that requirement as well? If >> so, that's a discussion that needs to be had ASAP. If not, then that's an >> implicit statement that it's okay for OpenID Connect implementations to not >> be best-practice OAuth implementations. And if that's the case, then I also >> think it's acceptable that they are not complete OAuth 2.1 implementations >> either. >> >> >> >> >> >> >> On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jones= >> 40microsoft....@dmarc.ietf.org> wrote: >> >>> The disadvantage of requiring PKCE for OpenID Connect implementations is >>> that you’re trying to add a normative requirement that’s not required of >>> OpenID Connect deployments today, which would bifurcate the ecosystem. >>> There are hundreds of implementations (including the 141 certified ones at >>> https://openid.net/certification/), none of which have ever been >>> required to support PKCE. Therefore, most don’t. >>> >>> >>> >>> Per feedback already provided, I believe that OAuth 2.1 should align >>> with the guidance already in the draft Security BCP, requiring EITHER the >>> use of PKCE or the OpenID Connect nonce. Trying to retroactively impose >>> unnecessary requirements on existing deployments is unlikely to succeed and >>> will significantly reduce the relevance of the OAuth 2.1 effort. >>> >>> >>> >>> In particular, authorization servers shouldn’t be required to support >>> PKCE when they already support the OpenID Connect nonce. And clients >>> shouldn’t reject responses from servers that don’t support PKCE when they >>> do contain the OpenID Connect nonce. Doing so would unnecessarily break >>> things and create confusion in the marketplace. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Dick Hardt >>> *Sent:* Wednesday, May 6, 2020 10:48 AM >>> *To:* oauth@ietf.org >>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE? >>> >>> >>> >>> Hello! >>> >>> >>> >>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is >>> best practice for OAuth 2.0. It is not common in OpenID Connect servers as >>> the nonce solves some of the issues that PKCE protects against. We think >>> that most OpenID Connect implementations also support OAuth 2.0, and >>> hence have support for PKCE if following best practices. >>> >>> >>> >>> The advantages or requiring PKCE are: >>> >>> >>> >>> - a simpler programming model across all OAuth applications and profiles >>> as they all use PKCE >>> >>> >>> >>> - reduced attack surface when using S256 as a fingerprint of the >>> verifier is sent through the browser instead of the clear text value >>> >>> >>> >>> - enforcement by AS not client - makes it easier to handle for client >>> developers and AS can ensure the check is conducted >>> >>> >>> >>> What are disadvantages besides the potential impact to OpenID Connect >>> deployments? How significant is that impact? >>> >>> >>> >>> Dick, Aaron, and Torsten >>> >>> >>> >>> ᐧ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no | >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
