- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 13 Apr 2015 23:51:43 -0400
- To: Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Mike West <mkwst@google.com>, Dan Veditz <dveditz@mozilla.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, Credentials Community Group <public-credentials@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
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:17 UTC