Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

[Vladimir Dzhuvinov <[e-mail]>]

Hi Dima,

A published RFC cannot be extended to specify new things, only have 
errata added it. The OAuth 2.1 spec is still a draft in the works.

What do you think is a suitable default value for a 
code_challenge_method client reg parameter?

 From the perspective of an OAuth 2.0 deployment it could be none (i.e. 
no PKCE) or S256, in the latter case a client will need to explicitly 
opt out of it, but how exactly?

 From the perspective of an OAuth 2.1 deployment it would be S256.



Vladimir Dzhuvinov

On 09/10/2022 02:33, Dima Postnikov wrote:
> Hi Vladimir.
>
> Client registration parameter sounds like a good idea to me.
>
> In terms of which document this goes to.... I wonder if PKCE RFC7636 
> could be updated to add this. This way ecosystems using PKCE in OAuth 
> 2.0 could benefit from this too.
>
> Thanks
>
> Dima
>
>
> On Sat, Oct 8, 2022 at 9:27 PM Vladimir Dzhuvinov 
> <[e-mail]> wrote:
>
>     Thanks for chiming in Dima.
>
>     Do you reckon it's a good idea to define a code_challenge_method
>     client reg parameter in the OAuth 2.1 spec?
>
>     To enable 2.0 -> 2.1 transitions and also give people a concrete
>     and standard compliant way to implement the "REQUIRED or
>     RECOMMENDED" in the OAuth 2.1 spec for code_challenge.
>
>     Another spec that deals with PKCE is the OAuth BCP, but to me
>     that's not a optimal place to define a new parameter.
>
>
>     Vladimir Dzhuvinov
>
>
>     On 08/10/2022 04:31, Dima Postnikov wrote:
>>     Hi Vladimir,
>>
>>     Similar issue exists in CDR (Australian Open Banking). PAR and
>>     PKCE was added as mandatory to FAPI 1 Advanced profile.
>>
>>     There was a transition period when AS had to support both
>>     (potentially).
>>
>>     Also if the same AS is used outside of CDR, this dual support
>>     would continue for some implementations.
>>
>>     I don't think this was solved, so your client registration
>>     parameter makes sense.
>>
>>
>>
>>     On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov
>>     <[e-mail]> wrote:
>>
>>         Has anyone faced the issue how an AS can handle a mix of
>>         OAuth 2.0 and
>>         2.1 clients regarding PKCE enforcement?
>>
>>         The new OAuth 2.1 spec makes PKCE required, which is a good
>>         security
>>         measure and fine for an AS where all clients are ready to
>>         comply with
>>         the upgrade. In practice however, it's common for AS
>>         deployments to have
>>         a mix of legacy 2.0 and 2.1 clients, and at present OAuth
>>         doesn't have a
>>         standard client registration parameter, e.g.
>>         code_challenge_method, to
>>         lock a client into using PKCE.
>>
>>         https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1
>>
>>         RFC 8414 defined the code_challenge_methods_supported
>>         metadata for
>>         servers. It would be useful if deployments had a
>>         corresponding parameter
>>         for the clients.
>>
>>         https://www.rfc-editor.org/rfc/rfc8414
>>
>>         ~ Vladimir
>>
>>         -- 
>>         Vladimir Dzhuvinov
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/oauth
>>