Re: Technical Review of WebAppSec Credential Management API [1/3] (was Re: Overlap with Credentials/Web Payments CG)

Thanks for this feedback, Manu! I've responded inline.

On Tue, Apr 14, 2015 at 5:51 AM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> * There is no mechanism to sync credentials between different browsers.
>   This leads to browser lock-in.
>

Why is syncing credentials between browsers a requirement for this feature?
It certainly seems nice to have, but browsers have password managers today
without interoperable sync, and that doesn't seem to be terrible. Why would
we block one improvement (adding an imperative, web-facing API) on another
(adding interoperable sync)?


> * Not having the ability to sync credentials between different browsers
>   removes features that people depend on from today's managers (like
>   LastPass) that allow you to do this. This makes the proposed solution
>   worse than the current solution.
>

I don't understand this point. Sync between different browsers' password
managers doesn't exist today. Given that status quo, how would adding this
API remove features from LastPass?


> * The design precludes any 3rd party provider from providing a
>   web-based secure credential store. This limits competition in this
>   space to just the browser vendors.
>

1. If this API takes off, I expect third-parties like LastPass, 1Password,
etc. to adjust their browser extensions to overwrite the API with their own
hooks (though ideally vendors would simply expose extension-level hooks,
making DOM injection unnecessary).

2. How does this API design preclude a third-party from providing anything?
I don't understand this fundamental aspect of the critique you're advancing.

* The API is primarily about managing passwords, not killing passwords.
>   We're standardizing the management of something that we know we don't
>   want in the future Web Platform. This extends the life of
>   password-based login, which we don't want to do.
>

Do you realistically expect passwords to die in the next year? Five years?
For better or worse, passwords are necessary on today's web. We should
support them today, while opening up avenues for the future. To that latter
point, the API is intended to be extensible through the definition of new
credential types. That's the main reason for the Credential -->
{Local,Federated}Credential inheritance structure, and the reason that
credential-specific operations like `send()` live on the subclasses. If we
determine in the future that there's a better way of doing authentication,
it should be quite straightforward to define and implement
`BetterCredential` in the same model.


> * The Federated Credential portion of the spec ensures that there will
>   only be login super-providers like Google and Facebook since it
>   requires developers to iterate over all the options. This leads to
>   login super-provider lock-in.
>

1. Folks use federated sign-in today to authenticate to websites. I hope
you'd agree that helping users do that well is a reasonable goal.

2. I hope the outcome is somewhat different than you expect. One reason
that websites _don't_ support more than a half-dozen identity providers is
the user paralysis that results from being presented with a long list of
logos. The browser can narrow that list down to just the providers you
actually use, making it more likely that you'll see those smaller IDPs with
whom you have a relationship.


> * The Federated Credential portion of the spec is poorly designed and
>   either a) precludes a richer Credential management mechanism in the
>   future, or b) assumes there will be two types of credential
>   management APIs in the future. Neither one of those is a good outcome.
>

Can you be more concrete? The current API returns a hint to the website
that it should, for example, kick off the Facebook SDK in response to a
user's request. I don't see any reason we couldn't add a
`grabAnAuthenticationToken()` method to `FederatedCredential` in the future
when we know how to do that. Or further subclass `FederatedCredential` into
`OAuthCredential`, `OAuth2Credential`, etc. Moreover, I don't see any
reason we couldn't add `RicherCredential` that had nothing to do with
either passwords or federations.

Basically, I accept that this proposal isn't going to cover all the use
cases we'll ever have in the future, and have attempted to design it such
that we can adapt as times change. Perhaps that's not coming across in the
current draft... Opened https://github.com/w3c/webappsec/issues/252 to
improve that.

Plan A
> 1. Rename the spec to something like "Login Management API", and
>

I'm happy to bikeshed the name. "Login Management" is somewhat limiting, as
we'd almost certainly ought to deal in some way with sign-up as well as
sign-in. I thought about "Authentication something something" as well, but
the API doesn't actually do authentication; it provides data that helps the
website authenticate a user. "Credential" seemed like a reasonable choice,
because the API is focused on storing and retrieving credential data.
*shrug* It still makes most sense to me, given that context, but it's worth
going a few rounds to see if we can come up with something better.

2. Remove any notion that you plan to support any sort of login
>    token aside from username/password and login super-provider. That
>    is, remove the "federated credential" bits that state that you
>    may consider different types of credentials in the future. The
>    current API design is not capable of supporting a broader goal.
>

I don't think your arguments so far justify this claim.


> Plan B
> 1. Work with the Web Payments IG and Credentials CG to support
>    different types of federated credentials other than the login
>    super-provider ones.
>

What kinds of federated credentials would you like to see us support?

It would result in a
> lightweight, unified API with relatively minor changes to the current
> proposal.
>

This sounds like a good outcome to aim for. What minor changes do you think
are necessary?

--
Mike West <mkwst@google.com>, @mikewest

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.)