Popup flow

Tue Sep 22 00:15:32 UTC 2009

Because mobile browsers do not often handle multiple windows well, I
would recommend the traditional redirect flow on mobile browsers.

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

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)