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

Hi Manu! Thanks for adding detail to your initial email. I didn't catch the
"[1/3]" part of the subject line, so I fear that this conversation could
become a bit confusing as it shards across multiple threads. I'll try to
respond inline below, but I suspect we're going to be a bit confused.
Perhaps we could just stay in this thread rather than further sharding the
conversation with a "3/3"?

I've cut out some bits that seemed repetitive (and I'd like to defer
discussion of the list of details at the bottom of your mail either to
explicit issues on GitHub, or a future thread), but this is still a huge
email. Apologies for that. I hope we can condense it down to some central
issues going forward.

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

> A person uses Google Chrome on their laptop and Safari on their iPhone.
> Assuming the success of this spec, how is that ecosystem supported?
>

This isn't a problem unique to the features this spec proposes. That is,
both of these browsers already have password managers, which are de facto
isolated sets of credentials, collected by isolated sets of proprietary
heuristics. Insofar as it's a problem, it's a problem that this spec
neither creates nor attempts to solve.

I think your claim is that this spec would make the problem worse by
encouraging websites to actively interact with the password manager,
thereby shutting extensions out? I can't speak for any vendor other than
Chrome, but in Chrome, extensions can already disable the embedded password
manager (via `chrome.privacy.settings.passwordSavingEnabled`), and can
already inject JavaScript that overwrites native implementations of DOM
methods. I fully expect extensions like LastPass, 1Password, etc to do both.


> I assert that without some sort of server-side component or export
> feature, it'll be harder to switch from one browser to another because
> all of your 20+ random character passwords will be locked into Google
> Chrome, forcing you to use Google Chrome across all of your devices.
>

1. De facto, every browser and password manager I've used has the ability
to forcibly import credentials from other browsers in the status quo. It's
not clear that a de jure standard is necessary, though I agree that it
would be nice to have.

2. It would, indeed, be good for browser vendors to offer explicit import
and export functionality. Again, that seems like a nice thing to do, but
not a necessary precondition for introducing an imperative API.


> A potential solution to this problem is to enable export or storage of
> credentials to a server-based component that allows credentials to be
> transported easily from one browser brand to another.
>

That is a potential solution. LastPass and others seem to be doing it
pretty well today, in fact.


> Does the spec provide a suggestion on allowing browser extensions to
> override navigator.credentials? If it does, are the security
> ramifications of doing so detailed anywhere? If it doesn't, isn't it
> making the state of the art worse by removing the ability to share
> credentials across multiple browser brands?
>

That's not a requirement the specification can make, however, as
proprietary extension platforms aren't part of the web. As noted above,
this is certainly what Chrome will do; other vendors will make their own
decisions.


> A potential solution to this problem is to spec a server-side component
> that allows credentials to be easily sync'd between browser brands.
>

That is a potential solution. It seems like it might be nice to have.


> Assuming a world where you have to provide a more complex credential,
> like an assertion that you're over the age of 21 so you can buy alcohol
> from a US online liquor store, how is that credential retrieved from the
> web-based credential storage mechanism? How is it stored locally?
> Updated? Issued from a government website and sent to the liquor store
> website?
>

If one wanted a browser to be able to interact with a third-party in order
to make such an assertion, this API would allow you to define a
`AgeVerificationCredential` with whatever metadata was necessary in order
to ask a third-party for age verification, and place whatever methods on
that object you deemed necessary for the assertion to be obtained and
delivered (with all of the security properties I'm sure you've put a lot of
thought into already).

It's not clear to me what aspects of the API design prevent that from being
possible.


> Since the spec seems to have larger goals (see "Future Work"), an API
> design that allows the credential request to be redirected to an
> external website and then the response posted back to a credential
> consuming URL on the Relying Party seems to be in order.
>

That might be necessary and desirable for some kinds of credentials. It
does not seem to be necessary for all kinds of credentials, so making it a
requirement in the API seems like unnecessary complexity. If and when we
decide to introduce support for such credentials, we can (easily?) define
an interface that makes sense.


> BrowserID was about killing the password and it got a lot of things
>
right. The Credential Management API seems like a big step backwards -
> standardizing the broken username/password scheme instead of replacing
> it with something better.
>

1. For better or worse, schemes like BrowserID have yet to obtain wide
acceptance in the market, while password are ubiquitous.

2. Password managers make users safer in a wide variety of ways. I can
enumerate advantages if you like, but I suspect we're on the same page here
already, given your LastPass advocacy above.

3. Making it easier for websites to integrate with password managers makes
it more likely that users will use password managers, and obtain the
advantages they provide, as long as password are still overwhelmingly used
for authentication.

This seems like a reasonable goal for the short-to-medium term.


> Worse, by standardizing the username/password login scheme, the spec is
> extending its lifespan, not reducing it.
>

Note that every mainstream browser already contains a password manager, and
already does its best to help users deal with the sign-in problem.


> A potential solution is to create a mechanism that takes advantage of
> some basic crypto, like BrowsrID did, to generate stronger login
> credentials.
>

This is a potential solution. It has the advantage of being theoretically
wonderful. It has the disadvantage of requiring authors to change.

I don't think anything in the proposed API would prevent interested folks
from defining a `HotNewCredential` type, and offering it to developers. In
fact, standardizing a nicely generic way of requesting and storing
credentials seems to be a nice way to make such a definition _easier_ for
developers to find, understand, and use.


> The code iterates over a number of federated identity providers. This
> approach ensures that there will only be a handful federated identity
> providers and people will not have a wide array of options on who to use
> for login. How big can this list get before developers get wary of
> having X different ways of logging into their website?
>

This is a social problem which exists in the status quo. For reasons,
Facebook's SDK is distinct from Twitter's SDK, which is distinct from
StackExchange's OpenID implementation: sites which want to support all of
these options need to include a number of different sign-in mechanisms.
Nothing about this spec changes that reality. I agree it would be nice to
change, but disagree that this spec makes the problem worse.

On the contrary, this spec makes it possible for a site to _meaningfully_
integrate more than one identity provider without giving their users a list
of options that they can't feasibly be expected to navigate. By specifying
the supported federations, and asking the user agent to match that list
against the local password store, users can make a decision between those
providers they already have relationships with. That seems like a nice way
of mitigating some of the badness of the underlying problem.


> A potential solution is to either standardize a federated identity
> provider response format so that a switch statement isn't necessary. For
> example, "this website trusts digital signatures from these 150
> federated identity providers for the purposes of login".
>

That is a potential solution. It has the disadvantage of requiring both
authors and identity providers to change.

Previous attempts to solve this problem (OAuth2, for instance) don't fill
me with confidence that it's a problem we can solve in the short-to-medium
term. If we do, great! We can define a `HotNewCredential` type to cover the
new hotness, implement it in all browsers, and be happy together. :)


> There is definitely an overlap with login and what I'll call "rich
> federated credentials" (drivers licenses, etc.). However, the overlap is
> just that "login" is only one type of credential in a sea of other kinds
> of credentials (like drivers licenses, professional licenses, age
> assertions, shipping addresses, etc.).
>

>From a user agent implementer's perspective, I'd suggest that "login" is a
very important kind of credential that every user agent I've used has
built-in support for. My claim is that that support is crippled by reliance
on proprietary heuristics, and can be significantly improved via an API
such as the one I've proposed.

To the extent that other types of credentials are important, I'd invite you
to explore the possibility of extending the proposed API with the kinds of
credentials you're interested in driving support for, and getting browser
vendors on board with implementing those extensions.


> Here are a few of the other problems related to federated credentials in
> the spec:
>

I'd suggest that these more detailed concerns hop over to
https://github.com/w3c/webappsec/issues/new?title=CREDENTIAL:%20 for
discussion, and that we keep this thread focused on the larger questions
you're raising.

Thanks!

-mike

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