- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 14 Apr 2015 01:20:01 -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 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