- From: Mike West <mkwst@google.com>
- Date: Tue, 14 Apr 2015 06:49:47 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Credentials Community Group <public-credentials@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
- Message-ID: <CAKXHy=eptD+c0jjcZe6ZjQ5hK-cYZFn1iZwq56Hc+=xgHHDdsg@mail.gmail.com>
Thanks for this feedback, Manu! I've responded inline. On Tue, Apr 14, 2015 at 5:51 AM, Manu Sporny <msporny@digitalbazaar.com> wrote: > * There is no mechanism to sync credentials between different browsers. > This leads to browser lock-in. > Why is syncing credentials between browsers a requirement for this feature? It certainly seems nice to have, but browsers have password managers today without interoperable sync, and that doesn't seem to be terrible. Why would we block one improvement (adding an imperative, web-facing API) on another (adding interoperable sync)? > * 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. > I don't understand this point. Sync between different browsers' password managers doesn't exist today. Given that status quo, how would adding this API remove features from LastPass? > * 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. > 1. If this API takes off, I expect third-parties like LastPass, 1Password, etc. to adjust their browser extensions to overwrite the API with their own hooks (though ideally vendors would simply expose extension-level hooks, making DOM injection unnecessary). 2. How does this API design preclude a third-party from providing anything? I don't understand this fundamental aspect of the critique you're advancing. * 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. > Do you realistically expect passwords to die in the next year? Five years? For better or worse, passwords are necessary on today's web. We should support them today, while opening up avenues for the future. To that latter point, the API is intended to be extensible through the definition of new credential types. That's the main reason for the Credential --> {Local,Federated}Credential inheritance structure, and the reason that credential-specific operations like `send()` live on the subclasses. If we determine in the future that there's a better way of doing authentication, it should be quite straightforward to define and implement `BetterCredential` in the same model. > * 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. Folks use federated sign-in today to authenticate to websites. I hope you'd agree that helping users do that well is a reasonable goal. 2. I hope the outcome is somewhat different than you expect. One reason that websites _don't_ support more than a half-dozen identity providers is the user paralysis that results from being presented with a long list of logos. The browser can narrow that list down to just the providers you actually use, making it more likely that you'll see those smaller IDPs with whom you have a relationship. > * 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. > Can you be more concrete? The current API returns a hint to the website that it should, for example, kick off the Facebook SDK in response to a user's request. I don't see any reason we couldn't add a `grabAnAuthenticationToken()` method to `FederatedCredential` in the future when we know how to do that. Or further subclass `FederatedCredential` into `OAuthCredential`, `OAuth2Credential`, etc. Moreover, I don't see any reason we couldn't add `RicherCredential` that had nothing to do with either passwords or federations. Basically, I accept that this proposal isn't going to cover all the use cases we'll ever have in the future, and have attempted to design it such that we can adapt as times change. Perhaps that's not coming across in the current draft... Opened https://github.com/w3c/webappsec/issues/252 to improve that. Plan A > 1. Rename the spec to something like "Login Management API", and > I'm happy to bikeshed the name. "Login Management" is somewhat limiting, as we'd almost certainly ought to deal in some way with sign-up as well as sign-in. I thought about "Authentication something something" as well, but the API doesn't actually do authentication; it provides data that helps the website authenticate a user. "Credential" seemed like a reasonable choice, because the API is focused on storing and retrieving credential data. *shrug* It still makes most sense to me, given that context, but it's worth going a few rounds to see if we can come up with something better. 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. > I don't think your arguments so far justify this claim. > 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. > What kinds of federated credentials would you like to see us support? It would result in a > lightweight, unified API with relatively minor changes to the current > proposal. > This sounds like a good outcome to aim for. What minor changes do you think are necessary? -- 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.)
Received on Tuesday, 14 April 2015 04:50:38 UTC