Part of the motivation behind that profile was to allow an autonomous client (no end-user identity passed to the AS) the ability to access a web service. In that case, I don't see what the client secret (along with the username and password) would be adding.
Ethan - assuming the token is signed by the authorization server, how can the client add data to it? -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David Recordon Sent: Monday, March 08, 2010 10:33 PM To: oauth-wrap...@googlegroups.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [WRAP] Username and Password Profile 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 <sshja...@gmail.com> 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 <record...@gmail.com> 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 <sshja...@gmail.com> >> 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 <a...@yahoo-inc.com> 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" <esjew...@gmail.com> wrote: >> >> >> >> > On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom <a...@yahoo-inc.com> >> >> > 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 >> >> OAuth@ietf.org >> >> 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 oauth-wrap...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > oauth-wrap-wg+unsubscr...@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/oauth-wrap-wg?hl=en. >> > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> 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 oauth-wrap...@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > _______________________________________________ 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
