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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
