Re: Proposal for a credential management API.

Hi Jonas, thanks for this feedback!

On Tue, Aug 12, 2014 at 11:51 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> I'm very interested in improving the login experience on websites. In
> particular I'd like to create a better flow when federated logins are
> used, with at least the following goals:
>

I think these are laudable goals. Taken together, I worry that we'll be
trying to boil the ocean, but I certainly agree with the general sentiment
and direction.


> * Enable the user to manage their accounts in browser chrome rather
> than have to go to specific websites to log out.
>

This will almost certainly require cooperation from both the RP and IDP
side of the equation. Given that, I worry that the browser will be
promising things that it can't actually guarantee if it pops up a "Sign
out" button.


> * Enable a login flow which is less "jarring" UX-wise than today's
> redirects.
> * Don't increase the number of clicks needed to log in. Today two
> clicks are usually enough, we shouldn't be worse than that since then
> websites won't adopt it and user's won't like it.
>

One-click sign-in (with a zero-click, "Keep me logged in" option) is a very
reasonable goal, and one that I think is achievable.

One- or two-click sign _up_, on the other hand, will likely be more
difficult given the complexities of authorization (scopes, etc).


> * Make it easier for websites to support multiple federated login
> providers by ensuring that they all use a common API. I.e. adding
> support for more login providers shouldn't need to require running
> code specific to that provider.
>

I worry about http://xkcd.com/927/. To pick on an easy target, there are
already several dialects of OAuth2 that IDPs provide SDKs to speak.
Moreover, it's not clear that any IDP actually considers this a bug.

Easy migration between IDPs is absolutely a benefit to the user, as is easy
integration with new IDPs for authors. It's something that we should
attempt to provide, but it is a large undertaking.


> * Enable the UA to track which login providers that the user has
> accounts with so that the UA can render UI which only displays
> providers that are relevant to the user.
>

The strawman I posted does this by using the password manager that's
already in browsers. If you've saved Funky Federation credentials, then the
UA can be reasonably sure that it should present you with that Funky option
when a website claims to support it. This seems like the simplest possible
way of getting the information, without requiring IDP support.


> All of these goals are likely not required. But I definitely want to
> make sure that whatever we build is attractive enough to users,
> webdevelopers and federated-login-providers that it actually gets
> used.
>

I agree that this is paramount.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)