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

[Adam Roach <[e-mail]>]

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