Yes. Some would be 2.0 and some2.1. Not unlike TLS versioning. Maybe i should not have said that. ;-)
Phil > On 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
