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

On 04/13/2015 02:05 AM, Anne van Kesteren wrote:
> You might want to try giving technical feedback before escalating.

Here is detailed technical feedback on the WebAppSec Credential
Management API. Thanks to Dave Longley for doing a thorough analysis
alongside mine today, many of these comments are his (that I also agree
with).

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

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

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.

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.

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

Applications like LastPass use a server-side component to enable you to
sync credentials between different browser brands. I don't see anything
like this in the current spec. Worse, it looks like the current spec is
going to put companies like LastPass out of business (if the spec
doesn't allow them to inject navigator.credentials).

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?

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

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

In the "Future Work" section, the spec suggests that perhaps this API
could be used to mediate the relationship between people, identity
providers, and websites. However, all credentials are stored locally in
the browser, effectively limiting the "identity provider" to a very
small set of super providers and then cutting them out from being able
to provide more useful credential data.

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?

The CredentialData object doesn't seem capable of supporting this use
case. Even if it was capable, it seems like all storage is local-only
and there is no mechanism for the identity provider to say when a
credential is updated or revoked.

This feature set isn't that vital for a simple Login Manager API where
the only thing you need to keep track of is username/password
combinations and super provider tokens. If that's all the spec purported
to do, then the design would be going in a good direction.

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.

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

A great portion of the API is devoted to storing username/password
combinations and retrieving them. This requires the person to initially
create a username/password per website.

The general rhetoric around passwords on the web for login is that
they're an anti-pattern. Yes, they exist and we have password managers
to handle them today, but we're clearly into an era where humans are not
capable of generating secure passwords.

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.

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

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

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

In this part of the spec:

https://w3c.github.io/webappsec/specs/credentialmanagement/#examples-federated-signin

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?

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

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

The "Federated Credentials" portion of the proposed spec is the most
concerning since it doesn't reference work being done for years in the
Web Payments CG, Credentials CG, or Web Payments IG groups.

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

The design of the Credentials Management API is backwards. The spec
shouldn't start with username+password/login-token and then try to fit
every other type of credential or credential request into that pattern.
Rather the problem should be approached from the other direction. A
website may require many different types of credentials, and a login
credential (such as an email assertion, like BrowserID) is just one type
of credential that should be stored/transmitted.

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

* Identity providers may not be browsers or browser-manufacturer
  companies. We don't want to lock people into identity providers.
  We want data and credential portability.
* Obtaining a credential may need to hit other websites, not just talk
  to a "credential/password manager" in a browser
* The types of federated credentials that the Credential CG is
  working on is more than just a "username+password" or "a login
  token", they can be a whole variety of information
* Sites may ask for different types of credentials based on different
  workflows. The current spec is limited to just two basic types of
  credentials.
* If the group is going to try and create a unified API, do it with all
  the federated/more broad credentials use cases first not narrow
  password/login use case above all others
* If the group only wants a password manager API, then do that, don't
  call it credentials; use navigator.passwordManager and there will
  be far less concern related to something the group probably
  never intended to touch.
* There's no mechanism for syncing credentials between different
  browsers -- mostly because the "login" case doesn't require it and it
  doesn't make as much sense there, another indication that the login
  use case isn't broad enough for designing a Credential Management API
* navigator.crededentials.get returns a promise, which doesn't really
  allow the browser to go off to another site to obtain credentials
  (without complex state management)
* The spec doesn't support any flows where you manage storage of
  credentials through federated entities, it all has to happen
  externally, it would be better to have a unified API for this,
  recommend passing a callback to receive POSTed credentials to the
  .get() call and the browser may then go to an identity provider's
  website to obtain the credentials and POST them back to that
  callback, or grab them from a local cache/manager and POST them
* navigator.credentials.get doesn't allow for querying for specific
  types of credentials, it assumes there's only one kind "login"
* Allow a callback to be passed to POST credentials to. If there's no
  callback URL, then .get() can return a promise for getting locally
  cached (eg: legacy login credentials) credential. If there is a
  callback URL, don't return a promise, instead browser goes to another
  site (IdP) and once it gets credentials, POST them to the callback
  URL (browser could still cache credentials without having to go to
  IdP, but it's just a cache, not the authoritative storage point)
* There's no reason to differentiate "LocalCredential" from
  "FederatedCredential" with the design proposed by the Credentials CG,
  they are all "Federated". This is a different design paradigm. It
  is not about managing passwords; that's legacy behavior.
* A Credential identifier (Credential.id) seems to be designed to hold
  an identifier for the user, which means there's just *one* credential
  for any user. The Credential CG use cases may require more than just
  one credential per user.
* There may be no name or avatarURL associated with a credential;
  again, the design seems to fit around login only and interaction with
  a UI for selecting a "credential for login"; it doesn't serve a wider
  variety of use cases defined by the Credentials CG
* Let IdP's provide these interfaces, don't require browsers to do it
  and don't limit it to name+avatarURL, allow innovation and IdP value
  add for screens for selecting credentials and how they are displayed
  Different types of credentials will require different displays:
  username+password may use an avatar image, but badges may look
  different, email address may be different, proof of age might be
  different, maybe it could be generalized to "a picture with a title",
  but maybe not, no reason to assume this or limit innovation in this
  space
* The browser is the gatekeeper for credentials, not your identity
  provider/credential service
* Credential display is limited to what you'd expect for a credential
  you use to log into a website
* Credentials are tied/stored for particular origins only, which is
  problematic when you have credentials that should be able to be
  used across different websites (like digital passports, drivers
  licenses, professional licenses, age proofs, etc.)

I hope all of these technical points underscore why I don't think the
Credential Management API is ready for FPWD. In the next email, I'll do
a thorough review of the text... but don't expect that for a few days as
that will take much more time to put together than the first two emails
in this thread.

-- manu

[1] https://w3c.github.io/webappsec/specs/credentialmanagement/

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Tuesday, 14 April 2015 05:20:36 UTC