W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

From: Erik Ros <mail@erikros.me>
Date: Tue, 14 Apr 2015 11:15:10 +0200
Message-ID: <552CDA9E.9040206@erikros.me>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:12 UTC