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

On 04/13/2015 01:23 PM, Brad Hill wrote:
> Before you continue tossing around threats of Formal Objections

It wasn't a threat; it was a statement of fact. I'm trying to help
prevent that from happening. To be clear, no one has filed a FO yet.

Here's an overview of the forthcoming technical review, which will
hopefully further underscore that I'm trying to help prevent various
groups at W3C from accidentally stepping all over each other.

Summary
-------

The WebAppSec Credential Management API[1] is problematic for the
following reasons:

* There is no mechanism to sync credentials between different browsers.
  This leads to browser lock-in.
* 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.
* 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.
* 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.
* 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.
* 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.

Paths Forward
-------------

There are two paths forward that would most likely lead to positive
outcomes for all groups involved.

Plan A
1. Rename the spec to something like "Login Management API", and
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.

OR

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.

Plan A will enable WebAppSec to make rapid progress toward standardizing
a login management API. I assert that the goal is misguided and you're
harming the Web Platform by extending the life of passwords. That said,
if the group still wants to go in that direction, I'm fine w/ it as long
as it doesn't negatively impact the work that the Credentials CG / Web
Payments IG are going to be doing over the next year.

Plan B will require coordination between multiple groups at W3C on a
better solution to the password-based login problem. The approach would
solve the problem that the WebAppSec Credential Management API is
attempting to solve as well as the "rich federated credential login"
problem that other groups are trying to solve. It would result in a
lightweight, unified API with relatively minor changes to the current
proposal.

I assert that Plan B is the right way to go and will try to make that
case in the next set of emails to the groups.

-- 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 03:52:15 UTC