Ah, gotcha, sorry for the misunderstanding. :) One thing I had thought of to mitigate the risk to the client, or at least allow the client the ability to see what data is going to be sent to the provider as "them" would be this: The user connects as 5.3 specifies, upon success the user is given a token. If the provider and client agree that the user now has authority to act as though all requests are coming from the client, the token is an access token. Otherwise, the client is given the option of being a proxy to all requests. The proxy would be an HTTP post from server to server in which the requested data would include the token the user received and the client's id and password. The client would then have the option of inspecting the data and allowing or denying requests that will be assumed to be made upon the clients behalf.
I realize that this is probably far more complex than desired. If, however, it is agreed that there is no way to assure that the client is ever who they say they are with this profile, at least giving the client the last authority on what is requested on their behalf could be optionally included. ~/Jason On Mon, Mar 8, 2010 at 10:33 PM, David Recordon <[email protected]> wrote: > Yes. I was agreeing with your point and suggesting that the profile > have the client secret added to the request. :) > > On Mon, Mar 8, 2010 at 9:12 PM, Jason Hullinger <[email protected]> > wrote: > > In the Spec (as of 0.9.7.2) for 5.3 (Username and Password profile) it > say's > > to make an HTTPS request using POST with the following parameters: > > > > wrap_client_id (the clients id) > > wrap_username (the users username) > > wrap_password (the users password) > > wrap_scope (optional scope defined by the provider) > > > > Are we talking about the same profile? > > > > ~/Jason > > > > On Mon, Mar 8, 2010 at 8:37 PM, David Recordon <[email protected]> > wrote: > >> > >> You wouldn't. The profile should include the client secret as well in > >> the initial request. You could always issue a client a different > >> secret for use with this profile as well. > >> > >> --David > >> > >> On Mon, Mar 8, 2010 at 8:22 PM, Jason Hullinger <[email protected]> > >> wrote: > >> > If one were to obtain the client id of a partner, under the vanilla > >> > username/password profile, how would a provider prevent non-partners > >> > from > >> > connecting to a provider who has implemented this profile? > >> > > >> > ~/Jason > >> > > >> > On Mon, Mar 8, 2010 at 8:01 PM, Allen Tom <[email protected]> wrote: > >> >> > >> >> Hi Ethan - > >> >> > >> >> In Yahoo's case, we only allow the username/password profile for a > very > >> >> small number of applications written by Yahoo or by partners under > >> >> contract, > >> >> and only when opening a web browser is not feasible or desirable. We > >> >> strongly discourage apps from using this profile, and it's unlikely > >> >> that > >> >> it'll ever be a public interface. > >> >> > >> >> We have a very strong preference that rich client apps invoke a > browser > >> >> window for the user to authorize the app. > >> >> > >> >> Other Service Providers have similar policies for their equivalent > >> >> username/password profile. > >> >> > >> >> Allen > >> >> > >> >> > >> >> > >> >> > >> >> On 3/8/10 6:51 PM, "Ethan Jewett" <[email protected]> wrote: > >> >> > >> >> > On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom <[email protected]> > >> >> > wrote: > >> >> >> This is why the username/password profile is intended for rich > >> >> >> client > >> >> >> apps, > >> >> >> where invoking a browser is not feasible. Given that the user > >> >> >> already > >> >> >> downloaded and installed the rich app, popping open a browser is > not > >> >> >> going > >> >> >> to protect the user from a malicious app for instance, a > malicious > >> >> >> app > >> >> >> could have installed a keylogger before invoking the browser. > >> >> > > >> >> > I disagree. There are a large and growing number of platforms on > >> >> > which > >> >> > I can install a rich client application and be confident that it > will > >> >> > not be able to recover my username and password when I type them > into > >> >> > my web browser. To name a few that I use every day: > >> >> > > >> >> > 1. My iPod Touch (non-jail-broken, admittedly) > >> >> > 2. Adobe AIR on my Windows XP system > >> >> > 3. Mac OS X (users and applications do not run as administrators by > >> >> > default) > >> >> > > >> >> > On a related note - What stops a provider from implementing the > >> >> > username/password pattern on top of normal OAuth or WRAP (thereby > >> >> > losing my business ;-)? The token can be pretty much any string of > >> >> > text, so the client could embed the username and password into the > >> >> > token. > >> >> > > >> >> > Ethan > >> >> > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> [email protected] > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "OAuth WRAP WG" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<oauth-wrap-wg%[email protected]> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/oauth-wrap-wg?hl=en. > >> > > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > You received this message because you are subscribed to the Google Groups > > "OAuth WRAP WG" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<oauth-wrap-wg%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
