- From: Erik Ros <mail@erikros.me>
- Date: Tue, 14 Apr 2015 11:15:10 +0200
- To: Wendy Seltzer <wseltzer@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Wendy, thank you for your response. It seems to me that there is a kernel of agreed upon functionality and there are many experiments being performed on it. In my view web 2.0 as a whole is a popular term for those experiments. Clearly, the efforts to try and standardize the functions, that the super providers haven't standardized so far, is a form of swimming against the stream. Why put our efforts in reconstruction when we could also dedicate our resources to creating a more democratic internet, by moving past all the lock in that currently exist. Let us not reinforce these undemocratic technologies. kind regards, Erik On 14-04-15 10:48, Wendy Seltzer wrote: > (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/ >>> > -- ========================= -- Erik Ros -- -- +447979090626 -- -- mail@erikros.me -- -- http://erikros.me -- -- @erikros_me -- -- +ErikRos_ejfrme -- =========================
Received on Tuesday, 14 April 2015 09:15:42 UTC