Sorry, I jumped the gun on my "related note". I don't think I really understood what was being discussed. So ... er ... ignore that suggestion please.
Ethan On Tue, Mar 9, 2010 at 11:23 AM, Justin Smith <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] On Behalf Of > David Recordon > Sent: Monday, March 08, 2010 10:33 PM > To: [email protected] > Cc: [email protected] > 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 <[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]. >>> > 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]. >> 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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
