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
