The code_challenge and code_challenge_method parameter names predate calling 
the spec PKCE.  

Given that some of us deployed early versions of PKCE in products and 
opensource to mitigate the problem before the spec was completed we decided not 
to rename the parameter names from code_verifier_method to 
pkce_verifier_method.  

For consistency we should stick with code_verifier_methods_supported in 
discovery.

John B.

> On Jan 21, 2016, at 3:12 AM, William Denniss <wdenn...@google.com> wrote:
> 
> "code_challenge_methods_supported" definitely works for me.
> 
> Any objections to moving forward with that? I would like to update our 
> discovery doc shortly.
> 
> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakim...@gmail.com 
> <mailto:sakim...@gmail.com>> wrote:
> Ah, OK. That's actually reasonable. 
> 
> 2016年1月21日(木) 9:31 nov matake <mat...@gmail.com <mailto:mat...@gmail.com>>:
> I prefer “code_challenge_methods_supported”, since the registered parameter 
> name is “code_challenge_method”, not “pkce_method".
> 
>> On Jan 19, 2016, at 11:58, William Denniss <wdenn...@google.com 
>> <mailto:wdenn...@google.com>> wrote:
>> 
>> Seems like we agree this should be added. How should it look?
>> 
>> Two ideas:
>> 
>> "code_challenge_methods_supported": ["plain", "S256"]
>> 
>> or
>> 
>> "pkce_methods_supported": ["plain", "S256"]
>> 
>> 
>> 
>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <tors...@lodderstedt.net 
>> <mailto:tors...@lodderstedt.net>> wrote:
>> +1
>> 
>> 
>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>> +1
>>> 
>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7...@ve7jtb.com 
>>> <mailto:ve7...@ve7jtb.com>> wrote:
>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>> 
>>> John B.
>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladi...@connect2id.com 
>>> > <mailto:vladi...@connect2id.com>> wrote:
>>> >
>>> > I just noticed PKCE support is missing from the discovery metadata.
>>> >
>>> > Is it a good idea to add it?
>>> >
>>> > Cheers,
>>> >
>>> > Vladimir
>>> >
>>> > --
>>> > Vladimir Dzhuvinov
>>> >
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> > https://www.ietf.org/mailman/listinfo/oauth 
>>> > <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to