<HTML>
<HEAD>
<TITLE>Re: Popup flow</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Yep- FWIW Facebook Connect for mobile uses full-page redirects for that reason.<BR>
<BR>
For the logout, I believe Breno or Allen wrote that as an extension which you can use.<BR>
<BR>
<BR>
On 9/21/09 5:15 PM, "Breno de Medeiros" <<a href="breno@google.com">breno@google.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Because mobile browsers do not often handle multiple windows well, I<BR>
would recommend the traditional redirect flow on mobile browsers.<BR>
<BR>
On Mon, Sep 21, 2009 at 5:10 PM, Jonathan Coffman<BR>
<<a href="jonathan.coffman@gmail.com">jonathan.coffman@gmail.com</a>> wrote:<BR>
> Do you all have examples of good mobile (or more specifically iPhone) OID or<BR>
> oAuth flows?<BR>
> (And thanks again for all of the great dialogue the last couple of days, I'm<BR>
> going to try my hardest to post as much about the system we're building as<BR>
> possible for the benefit of the community.)<BR>
> We're going to try a quick and dirty federated logout (RP pushes logout back<BR>
> up to the OP) and see how people respond, I think it might make for an<BR>
> interesting case-study as a positive, or maybe even a negative?.<BR>
> -Jonathan<BR>
> On Sep 21, 2009, at 7:01 PM, Chris Messina wrote:<BR>
><BR>
> To Darren's point — there are OAuth applications that encapsulate the entire<BR>
> experience within an embedded WebKit view, or with an iframe.<BR>
> This is also bad, but unfortunately, too many developers using OAuth seem<BR>
> willing to sacrifice their customer's security for a better user experience.<BR>
> This is regrettable, to be sure, and selfish at worst.<BR>
> While OAuth makes the situation better in degrees, the typical OAuth<BR>
> argument suggests that if you're a desktop app, "you can get the user's<BR>
> credentials" if you want them. That's a naive and arrogant perspective, but<BR>
> is quite common.<BR>
> The point is not whether the developer is evil or not, but whether other<BR>
> applications and actually evil developers are able to take advantage of<BR>
> these behaviors, either to trick users who think that entering their<BR>
> credentials into any username/email + password form is okay, or where other<BR>
> native applications leak a user's passwords because the system itself is<BR>
> infected with some kind of malware. If apps never ask for or accept user<BR>
> passwords, then the worst thing that can happen is based on the permissions<BR>
> afforded the app's tokens — and if the developer is security conscious, he<BR>
> will have only asked for the permissions that he's looking for.<BR>
> Unfortunately, we're going to have to see a few people get badly burned<BR>
> before this behavior changes.<BR>
> Remember, we're still largely in the era of desktop-based virus scanners —<BR>
> few people install "virus scanners" in their social networking profiles.<BR>
> Chris<BR>
> On Mon, Sep 21, 2009 at 3:36 PM, David Recordon <<a href="recordond@gmail.com">recordond@gmail.com</a>> wrote:<BR>
>><BR>
>> Hey Darren,<BR>
>> I'm confused. The OAuth protocol doesn't use embedded iframes either.<BR>
>> It supports redirects like OpenID and now via the OpenID User<BR>
>> Experience Extension combined with the OpenID and OAuth Hybrid<BR>
>> protocol, popups.<BR>
>><BR>
>> --David<BR>
>><BR>
>> On Mon, Sep 21, 2009 at 1:28 PM, Darren Bounds <<a href="dbounds@gmail.com">dbounds@gmail.com</a>> wrote:<BR>
>> > I find it curious that these compromises have been embraced by the<BR>
>> > OAuth community to support a greater UX but they are not being<BR>
>> > embraced by OpenID. After all, isn't an iPhone UIWebView control just<BR>
>> > a different type of iFrame? You're still trusting parent application<BR>
>> > not to do something malicious.<BR>
>> ><BR>
>> > On Mon, Sep 21, 2009 at 12:24 PM, Chris Messina<BR>
>> > <<a href="chris.messina@gmail.com">chris.messina@gmail.com</a>> wrote:<BR>
>> >> 2009/9/21 Steven Livingstone Pérez <<a href="weblivz@hotmail.com">weblivz@hotmail.com</a>><BR>
>> >>><BR>
>> >>> I would have thought an IFrame injected into the page woudn't cause<BR>
>> >>> popup<BR>
>> >>> issues.<BR>
>> >><BR>
>> >> Injected iframes are a bad idea — especially ones that ask you to enter<BR>
>> >> your<BR>
>> >> credentials.<BR>
>> >> Indeed, while the injected iframe approach has certainly usability<BR>
>> >> benefits<BR>
>> >> (i.e. no new windows to lose track of) they present untenable security<BR>
>> >> issues that, ultimately, mean that they cannot be used.<BR>
>> >> Facebook has been somewhat erratic in its enforcement of the popup flow<BR>
>> >> —<BR>
>> >> making exceptions for certain partners. The problem is not the good<BR>
>> >> actors<BR>
>> >> who implement the technology correctly, though, it's that users don't<BR>
>> >> develop an expectation to look for the popup, which affords them<BR>
>> >> certain<BR>
>> >> security-enhancing signals, like the URL bar, the presence of the HTTPS<BR>
>> >> indicator and so on.<BR>
>> >> Even if most people ignore these things, for those who *know* to<BR>
>> >> inspect<BR>
>> >> them, the popup is an order of magnitude more security-preserving.<BR>
>> >><BR>
>> >>><BR>
>> >>> Is the popups generally going to be new window instances? I'd be<BR>
>> >>> surprised<BR>
>> >>> if the is the suggested way.<BR>
>> >><BR>
>> >> I think we'll go through a transitional period. The big OpenID provider<BR>
>> >> would likely prefer the popup method — which is less obtrusive than the<BR>
>> >> full<BR>
>> >> window redirect, which can be confusing for some users.<BR>
>> >> More usability research is needed here — and that research needs to be<BR>
>> >> shared with the wider community so that we understand what the typical<BR>
>> >> user<BR>
>> >> mental model is of signing in — and whether they can comprehend why<BR>
>> >> they're<BR>
>> >> sent back to their provider, rather than logged in directly.<BR>
>> >> Chris<BR>
>> >><BR>
>> >>><BR>
>> >>> steven<BR>
>> >>> <a href="http://livz.org">http://livz.org</a><BR>
>> >>><BR>
>> >>> ________________________________<BR>
>> >>> Date: Sun, 20 Sep 2009 17:38:19 -0700<BR>
>> >>> Subject: Re: Popup flow<BR>
>> >>> From: <a href="chris.messina@gmail.com">chris.messina@gmail.com</a><BR>
>> >>> To: <a href="openid-user-experience@lists.openid.net">openid-user-experience@lists.openid.net</a><BR>
>> >>><BR>
>> >>><BR>
>> >>><BR>
>> >>> On Sun, Sep 20, 2009 at 1:12 PM, Jonathan Coffman<BR>
>> >>> <<a href="jonathan.coffman@gmail.com">jonathan.coffman@gmail.com</a>> wrote:<BR>
>> >>><BR>
>> >>> Are there concerns over users with ad-blockers or pop-up blockers and<BR>
>> >>> being able to reach the OpenID flow?<BR>
>> >>><BR>
>> >>> There are some, yes. This needs to be widely tested, but we're able to<BR>
>> >>> get<BR>
>> >>> around (read: interact with correctly) because the pop-up is launched<BR>
>> >>> by<BR>
>> >>> user action, rather than automatically.<BR>
>> >>> Facebook seems to use this method without a problem, so perhaps Luke<BR>
>> >>> has<BR>
>> >>> some insights.<BR>
>> >>> Chris<BR>
>> >>><BR>
>> >>><BR>
>> >>> On Sep 19, 2009, at 11:32 PM, Allen Tom wrote:<BR>
>> >>><BR>
>> >>> Jonathan Coffman wrote:<BR>
>> >>><BR>
>> >>> In seeing Yahoo's announcement of their pop-up flow, and Google's<BR>
>> >>> previous<BR>
>> >>> migration -- is this quickly becoming the defacto standard?<BR>
>> >>><BR>
>> >>> Hi Jonathan,<BR>
>> >>><BR>
>> >>> Yahoo's usability testing indicates that the new OpenID popup flow<BR>
>> >>> performs better than then old redirect flow, and this is also<BR>
>> >>> consistent<BR>
>> >>> with Facebook's experience with Connect.<BR>
>> >>><BR>
>> >>> The popup flow is currently an extension, meaning that it's optional,<BR>
>> >>> and<BR>
>> >>> it's the RP's choice to invoke either the popup or redirect. If you<BR>
>> >>> have the<BR>
>> >>> resources to experiment with both flows in a production environment,<BR>
>> >>> definitely everyone would be very interested in the results.<BR>
>> >>><BR>
>> >>> Some of my stakeholders are asking for a templated/co-branded<BR>
>> >>> experience<BR>
>> >>> so that users, when redirected, see a logo, etc from the RP on the<BR>
>> >>> sign-up/log-in page for our OP. Obviously, that's not too difficult to<BR>
>> >>> do<BR>
>> >>> but I feel like the whole argument might be overcome with a simplified<BR>
>> >>> OP<BR>
>> >>> design by utilizing the popup draft spec.<BR>
>> >>><BR>
>> >>> Section 6 in the Draft User Interface spec defines a mechanism for the<BR>
>> >>> RP<BR>
>> >>> to pass its logos to the OP. Showing the RP's logos to the user on the<BR>
>> >>> OP's<BR>
>> >>> approval/login screens definitely is very helpful to users, and<BR>
>> >>> feedback<BR>
>> >>> from our testers in our usability labs was overwhelmingly positive<BR>
>> >>> when we<BR>
>> >>> did this.<BR>
>> >>><BR>
>> >>> Speaking on behalf of Yahoo, there are issues with displaying metadata<BR>
>> >>> about the RP that was not manually reviewed for correctness by the OP.<BR>
>> >>> For<BR>
>> >>> instance, the RP could be a malicious site that is pretending to be a<BR>
>> >>> trusted site, such as a bank. The malicious RP could misrepresent<BR>
>> >>> itself by<BR>
>> >>> passing the bank logo to the OP.<BR>
>> >>><BR>
>> >>> Other OPs that are planning to supporting the RP Icons portion of the<BR>
>> >>> UI<BR>
>> >>> Extension may have other opinions about how important it is for OPs to<BR>
>> >>> manually verify the RP's logos before displaying them to the user.<BR>
>> >>><BR>
>> >>> An alternative approach for having the RP pass metadata about itself<BR>
>> >>> to<BR>
>> >>> the OP (including icons, name, description) would be to use the OpenID<BR>
>> >>> OAuth<BR>
>> >>> Hybrid Extension, and have all the RP metadata bound to the RP's OAuth<BR>
>> >>> consumer_key. Most OAuth service providers usually have certain<BR>
>> >>> business/legal criteria to issue an OAuth consumer_key, and in Yahoo's<BR>
>> >>> case,<BR>
>> >>> business partners are allowed to have logos assocaited with their<BR>
>> >>> consumer<BR>
>> >>> key, and all of these logos are manually reviewed before being<BR>
>> >>> enabled.<BR>
>> >>><BR>
>> >>> Thanks<BR>
>> >>> Allen<BR>
>> >>><BR>
>> >>><BR>
>> >>><BR>
>> >>> _______________________________________________<BR>
>> >>> user-experience mailing list<BR>
>> >>> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> >>> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
>> >>><BR>
>> >>> _______________________________________________<BR>
>> >>> user-experience mailing list<BR>
>> >>> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> >>> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
>> >>><BR>
>> >>><BR>
>> >>><BR>
>> >>> --<BR>
>> >>> Chris Messina<BR>
>> >>> Open Web Advocate<BR>
>> >>><BR>
>> >>> Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><BR>
>> >>> Follow me on Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><BR>
>> >>><BR>
>> >>> Citizen Agency: <a href="http://citizenagency.com">http://citizenagency.com</a><BR>
>> >>> Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><BR>
>> >>> OpenID Foundation: <a href="http://openid.net">http://openid.net</a><BR>
>> >>><BR>
>> >>> This email is: [ ] bloggable [X] ask first [ ] private<BR>
>> >>><BR>
>> >>> ________________________________<BR>
>> >>> Hotmail: Powerful Free email with security by Microsoft. Get it now.<BR>
>> >>> _______________________________________________<BR>
>> >>> user-experience mailing list<BR>
>> >>> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> >>> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
>> >>><BR>
>> >><BR>
>> >><BR>
>> >><BR>
>> >> --<BR>
>> >> Chris Messina<BR>
>> >> Open Web Advocate<BR>
>> >><BR>
>> >> Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><BR>
>> >> Follow me on Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><BR>
>> >><BR>
>> >> Citizen Agency: <a href="http://citizenagency.com">http://citizenagency.com</a><BR>
>> >> Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><BR>
>> >> OpenID Foundation: <a href="http://openid.net">http://openid.net</a><BR>
>> >><BR>
>> >> This email is: [ ] shareable [X] ask first [ ] private<BR>
>> >><BR>
>> >> _______________________________________________<BR>
>> >> user-experience mailing list<BR>
>> >> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> >> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
>> >><BR>
>> >><BR>
>> ><BR>
>> ><BR>
>> ><BR>
>> > --<BR>
>> ><BR>
>> > Thank you,<BR>
>> > Darren Bounds<BR>
>> > _______________________________________________<BR>
>> > user-experience mailing list<BR>
>> > <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> > <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
>> ><BR>
>> _______________________________________________<BR>
>> user-experience mailing list<BR>
>> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
><BR>
><BR>
><BR>
> --<BR>
> Chris Messina<BR>
> Open Web Advocate<BR>
><BR>
> Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><BR>
> Follow me on Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><BR>
><BR>
> Citizen Agency: <a href="http://citizenagency.com">http://citizenagency.com</a><BR>
> Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><BR>
> OpenID Foundation: <a href="http://openid.net">http://openid.net</a><BR>
><BR>
> This email is: [ ] shareable [X] ask first [ ] private<BR>
> _______________________________________________<BR>
> user-experience mailing list<BR>
> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
><BR>
><BR>
> _______________________________________________<BR>
> user-experience mailing list<BR>
> <a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
> <a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
><BR>
><BR>
<BR>
<BR>
<BR>
--<BR>
--Breno<BR>
<BR>
+1 (650) 214-1007 desk<BR>
+1 (408) 212-0135 (Grand Central)<BR>
MTV-41-3 : 383-A<BR>
PST (GMT-8) / PDT(GMT-7)<BR>
_______________________________________________<BR>
user-experience mailing list<BR>
<a href="user-experience@lists.openid.net">user-experience@lists.openid.net</a><BR>
<a href="http://lists.openid.net/mailman/listinfo/openid-user-experience">http://lists.openid.net/mailman/listinfo/openid-user-experience</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>