+1. Even as the main editor of the spec., I tend to forget the history ;-) 2016年1月21日(木) 23:17 John Bradley <ve7...@ve7jtb.com>:
> 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> wrote: > >> Ah, OK. That's actually reasonable. >> >> 2016年1月21日(木) 9:31 nov matake <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> 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> 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> 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> 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 >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://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 >>> >> > _______________________________________________ > 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
