Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[William Denniss <[e-mail]>]

On Tue, May 23, 2017 at 10:27 AM, Adam Roach <[e-mail]> wrote:

> William --
>
> Thanks for your quick responses! I have only one follow-up (beyond my
> response to the thread that Alexey started):
>
> On 5/22/17 17:14, William Denniss wrote:
>
> My understanding of the Web Authentication Broker is that it is
> effectively a special-case browser designed for authentication. There is a
> single cookie-jar which is retained and used with all apps that use the Web
> Authentication Broker in "SSO mode". So logins are shared, and the
> advantages of Section 4 apply.  It's a separate cookie-jar from the main
> browser, which would imply a minimum of two sign-ins on the device (so not
> quite "single" at a device level), but I'm not sure if this is enough to
> disqualify it.
>
> My goal here is to simply document the current state of the art of the
> platforms, and I felt that the Web Authentication Broker qualified as an
> external user agent per the BCP.  The user interface is arguably quite nice
> too, which mitigates some of the downsides of using a special
> authentication "browser" with a separate cookie jar.
>
>
> Some of this comes down to user experience and some of it comes down to
> user choice. I'm going to speak using first-person pronouns here, but
> please be aware that I'm speaking from the point of view of a significant
> body of users.
>
> For the user experience side of things: users of Firefox and Chrome will
> commonly take advantage of cross-machine, cross-platform password
> synchronization built into those browsers, and the recommendation you're
> giving in this document defeats those pretty soundly. Thinking all the way
> through the user experience you're promoting, here's what this would look
> like to me:
>
>    1. Native app has a button I can use to [link an account, authenticate
>    myself, etc]
>    2. I click that button, and the Web Authentication Broker opens
>    3. I manually open Firefox, go to options->security, and click on
>    "saved logins"
>    4. I type in the name of the authenticating website, click on "Show
>    Passwords," and enter my master password
>    5. I copy and paste the (long, randomly-generated) password for the
>    authenticating website into the Web Authentication Broker
>
> That's... pretty friction-laden, especially when you consider that opening
> the authentication flow in my native browser would take maybe one or two
> clicks instead. The situation for Chrome users is approximately as bad.
>
>
> The other part of this recommendation (and I think this is a bigger issue)
> is that I, as a user, have made a pretty conscious decision about the
> browser I want to use for these kinds of things, based in part on the way I
> know various browsers handle things like analytics and privacy, and based
> in part on the speed with which browser security exploits are patched. I'm
> going to presume that the Web Authentication Broker acts in every way that
> I care about like either Edge or Explorer (probably Edge), which is likely
> to fall outside the envelope of what I'm okay with in a browser. I don't
> mean this as a major knock on Edge; I just have certain preferences in this
> area, and it's a choice that I feel I should be allowed to make and have
> respected when possible.
> This section is written in a way that reads very much like "use the Web
> Authentication Broker when possible, and fall back on the user's explicitly
> selected and preferred browser only as a last resort." This circumvents the
> user agency I describe above, which gives me more than a little cause for
> concern.
>
> For these two reasons, I would like to see the recommendation in this
> section pretty much reversed: calling to to the browser registered with the
> operating system should be preferred so as to respect user agency, followed
> by a note that using the Microsoft Web Authentication Browser in SSO Mode
> qualifies as using an External Browser as described in this document,
> although it has the three drawbacks of:
>
>    1. Not integrating with cookie storage for the user's preferred
>    browser.
>    2. Not integrating with password management for the user's preferred
>    browser.
>    3. Bypassing user choice regarding various browser attributes, such as
>    privacy and security properties.
>
>
> /a
>

In my staged copy
<https://github.com/WilliamDenniss/draft-ietf-oauth-native-apps/pull/9/files>,
I have followed your advice and reversed the recommendation ordering, and
mentioned the caveats that the user's personalisations are not present in
the broker. The lack of password manager support is a very good point. It's
definitely been one of the advantages we've seen by moving to browsers from
web-view.