- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Tue, 14 Apr 2015 04:48:48 -0400
- To: Erik Ros <mail@erikros.me>, Manu Sporny <msporny@digitalbazaar.com>, Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
(moving WebPayments IG and Credentials CG to BCC) May I ask people to limit the cross-posting in this thread? Feel free to post to the public-webappsec list and use its github repository[1] to raise issues against the current credential-management draft. As I see it, the chief inquiry here before FPWD is whether the proposed credential management spec in WebAppSec is incompatible with other technologies in use or in development, not whether there are bigger and greater things that could also be done. Our aim in standardization is to start with a kernel of agreed-upon functionality to provide a platform for experimentation from which people can develop the next great thing -- that they can propose in turn in the next round of standardization. Thanks, --Wendy [1] https://github.com/w3c/webappsec/tree/master/specs/credentialmanagement On 04/14/2015 04:34 AM, Erik Ros wrote: > There are so many +1's in Manu's last email, it blows my mind > > @mike you must see that this idea is much more exciting then the one you > are proposing. I like to ask you to buy into these ideas and get the > google behind it as well. Kick this new technologies into the > stratosphere! Let's make the inter-webs a truly mind blowing experience > again. > > and to respond to this rhetorical question: > > How big can this list get before developers get wary of > having X different ways of logging into their website? > > After zero different ways (specially if the first option is by one of > the super providers), because let's face it, all the cool kids don't > have Facebook or Google. > > let's come together and make some magic! > > kind regards, > > Erik > > On 14-04-15 07:20, Manu Sporny 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. >> >>> * 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/ >> > -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile)
Received on Tuesday, 14 April 2015 08:48:55 UTC