On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav <[email protected]> wrote: > 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.
Let's pretend we're talking about a human user instead of an API client. The user enters their username, and their password. They get a token that can be used to access resources. Those might not be their resources; they might be viewing a friend's calendar, for example. Would you say calling that a "user password" profile would be misleading? Because the grant isn't just for the user's own resources? My guess is not. What we are doing with the client password profile is exactly equivalent. Except instead of a human user, we're dealing with an API client. Cheers, Brian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
