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<oauth-wrap-wg%2bunsubscr...@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
