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
