Can you clarify what you mean by autonomous? Isn't the wrap_username an end user identity?
Sent from my iPhone On Mar 9, 2010, at 8:25 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 oauth-wrap- >>>> [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
