Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Nov Matake <[e-mail]>]

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 <[e-mail]>のメール:
> 
> 
>> 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 <[e-mail]> 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 <[e-mail]> 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. 
>> > 
>>