The use case is pretty simple: the user uses the server and approves a third party site access to their data directly (i.e. They are not sent to the server from the client, but just use the server). The third part then uses their client credentials to request a token. That token has access to whatever data was authorized previously by any user on the server side. This is still a client-only flow, but the grant isn't just for the client's own resources, but to whatever has been authorized to that client.
All I was trying to say was that when the client uses client credentials alone, it can access resources beyond those under its control (i.e. Its own resources) if such grant was previously arranged. For example, I think FireEagle had an API to ask if any of the users who authorized a client have changed location since last time the client checked. That was done using a client-only token, but it provided some information about individual users (which one was updated). IOW, the client-credentials flow is not limited to cases where the client is also the resource owner. The client can also access other resources as authorized. EHL On 7/17/10 8:52 AM, "Luke Shepard" <lshep...@facebook.com> wrote: 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
