client credentials works for me as well.
On Mon, Jul 19, 2010 at 10:17 AM, Justin Richer <[email protected]> wrote: > "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
