Facebook does need to implement this - formerly the "client_cred" flow. We need apps to be able to interact directly with the service without a user involved.
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. We wouldn't call it the "client secret" flow because the client secret is used in other flows; I think the same argument applies to the term "client password". How about just "client_only" ? Eran, I don't think I understand the other use cases you're talking about. On Jul 16, 2010, at 3:27 PM, Brian Eaton wrote: > I withdraw my question. David might not be interested in implementing > the client password flow, but he is certainly interested in > implementing other flows that involve the client password term. So > he's entitled to an opinion on what color the client password bike > shed should be painted. =) > > (David, no offense, I'm just trying to stick by my guns on the whole > "stop screwing up the spec by merging separate use cases into single > flows" thing...) > > On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> And that matters how? >> >> EHL >> >> >> >> On Jul 16, 2010, at 16:57, "Brian Eaton" <bea...@google.com> wrote: >> >>> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon <record...@gmail.com> wrote: >>>> I've always found "client password" to be a confusing term. >>> >>> Are you going to support this flow at all...? >>> _______________________________________________ >>> 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
