"client_credentials" is fine with me for the name of this grant type. I'd also like the paragraph describing its use to be pulled out into a subsection, to be parallel with all the other grant types.
-- Justin On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote: > client_credentials worked fine before. I'll just replace none with that. No > one had an issue with the name in -05. > > EHL > > > > On Jul 17, 2010, at 15:49, Brian Eaton <[email protected]> wrote: > > > On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard <[email protected]> wrote: > >> As far as consistency, it is just a little weird to call it "client > >> password" in one > >> part of the spec, when it's defined as "client secret" elsewhere. > > > > Agreed, we could be more consistent. The value we're talking about is > > the same in all of the flows, no sense in switching terminology. > > > > I prefer client_password, because "password", for me, evokes all the > > right kinds of security concerns. Password storage, encryption on the > > wire, etc... > > > > I'm less happy with client_secret, though I can certainly live with > > it. My main concern with client_secret is that people might confuse > > it with a signing secret. The value is not used for signing. If we > > are going to have flows where clients have secrets that are used for > > cryptographic authentication, then I would want to call those "keys" > > instead. > > > >> How about just "client_only" ? > > > > That would be fine by me. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
