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

et al.

I'm very concerned with the implications of this FPWD being published
without consensus.  Accreditrust has and is still actively recruiting
existing and potentially new W3C members who have expertise in the area of
digital credentials. We helped found the Credentials Community Group
http://www.w3.org/community/credentials/ and its charter for the purposes
of bringing together subject matter experts to establish use cases,
specifications and vocabularies that address digital credential
stackholders as a whole.  Should this FPWD move forward without consensus,
the CCG's ability to continue to recruit members, and convince them that
their input is being represented will be thwarted.  To date, our efforts at
the CCG have established the need for portability (no vendor lock-in, no
need for "super providers"), data extensibility (JSON-LD, schema.org
support), digital signatures (LD / HTTP Signatures), and the ability to
perform independent verification of a credential's primary source data.
While the FPWD does not need to support all of these requirements, it
should also not prevent them from being a possibility. It is currently not
clear if these cases are hindered by the FPWD, so I hope that we can work
through the issues below before a FPWD is published.

I believe that collaboration between these groups is necessary. I would
welcome the opportunity to discuss how ALL the efforts can serve the entire
W3C community, rather than just a few.   I also think it important we not
only discuss the technical merits of these solutions, but also the business
cases, since there are many who are depending building commercially viable
services based on adopted standards.

See my +1/-1 below.

----------------------------------
Eric Korb, President/CEO - accreditrust.com <https://www.accreditrust.com>
http://www.linkedin.com/in/erickorb @erickorb @accreditrust

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

> 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.
>
+1

>
> > * 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).
>
+1

>
> 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?
>
+1

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

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

>
> 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.
>
+1

>
> 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.
>
+1

>
> 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.
>
+1

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

>
> 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.
>
+1

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

>
> 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.
>
+1

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

>
> > * 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.).
>
+1

>
> 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.
>
+1

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

>
> 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/

-1 FPWD

>
>
> --
> 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/
>
>