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

Good afternoon. Just to get this out there, I am a nobody civilian in the standards space. I am not a W3C member, nor presently attached to one (that may change in the near future). I am only a volunteer in the Community Group CG offering my limited time because I believe it has real potentially to materially impact the world in very interesting, powerful, useful and positive ways.

I am, however, a highly visible public developer-facing standards advocate who has been trying to get developers to care about W3C standards for over ten years. I speak to between 2,000-4,000 developers around the world annually highlighting the good work that is done here. To the extent that I am able to get them excited about standards, it is because the W3C sometimes appears as if it is a deliberate and thoughtful organization attempting to solve hard problems for everyone with compatible technologies. To the extent that there is confusion, competing standards, arbitrary, narrowly-focused agendas encoded as specs, short-term bandwagon thinking, the whole thing appears to be a waste of time and developers return to their default position of ignoring any standards they can.

From my Outsider position, it appears that there is not a tremendous amount of conflict here. There are two groups doing good work that, at a minimum, bump into each other or will at least appear to publicly. I encourage the groups to collaborate and perpetuate the thoughtful and problem-solving perspective. I acknowledge that will take at least a short extra amount of time to find the overlap and opportunities to produce a superior set of standards, but I believe it will be worth it.

This is an example where this can move forward positively and deliberately or fall off the rails. People will notice the outcome in either case and choose whether to respect or ignore your significant efforts.

> On Apr 14, 2015, at 1:30 AM, Mike West <mkwst@google.com> wrote:
> 
> Hi Manu! Thanks for adding detail to your initial email. I didn't catch the "[1/3]" part of the subject line, so I fear that this conversation could become a bit confusing as it shards across multiple threads. I'll try to respond inline below, but I suspect we're going to be a bit confused. Perhaps we could just stay in this thread rather than further sharding the conversation with a "3/3"?
> 
> I've cut out some bits that seemed repetitive (and I'd like to defer discussion of the list of details at the bottom of your mail either to explicit issues on GitHub, or a future thread), but this is still a huge email. Apologies for that. I hope we can condense it down to some central issues going forward.
> 
> On Tue, Apr 14, 2015 at 7:20 AM, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
> A person uses Google Chrome on their laptop and Safari on their iPhone.
> Assuming the success of this spec, how is that ecosystem supported?
> 
> This isn't a problem unique to the features this spec proposes. That is, both of these browsers already have password managers, which are de facto isolated sets of credentials, collected by isolated sets of proprietary heuristics. Insofar as it's a problem, it's a problem that this spec neither creates nor attempts to solve.
> 
> I think your claim is that this spec would make the problem worse by encouraging websites to actively interact with the password manager, thereby shutting extensions out? I can't speak for any vendor other than Chrome, but in Chrome, extensions can already disable the embedded password manager (via `chrome.privacy.settings.passwordSavingEnabled <http://chrome.privacy.settings.passwordsavingenabled/>`), and can already inject JavaScript that overwrites native implementations of DOM methods. I fully expect extensions like LastPass, 1Password, etc to do both.
>  
> 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.
> 
> 1. De facto, every browser and password manager I've used has the ability to forcibly import credentials from other browsers in the status quo. It's not clear that a de jure standard is necessary, though I agree that it would be nice to have.
> 
> 2. It would, indeed, be good for browser vendors to offer explicit import and export functionality. Again, that seems like a nice thing to do, but not a necessary precondition for introducing an imperative API.
>  
> 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.
> 
> That is a potential solution. LastPass and others seem to be doing it pretty well today, in fact.
>  
> 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?
> 
> That's not a requirement the specification can make, however, as proprietary extension platforms aren't part of the web. As noted above, this is certainly what Chrome will do; other vendors will make their own decisions.
>  
> A potential solution to this problem is to spec a server-side component
> that allows credentials to be easily sync'd between browser brands.
> 
> That is a potential solution. It seems like it might be nice to have.
>  
> 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?
> 
> If one wanted a browser to be able to interact with a third-party in order to make such an assertion, this API would allow you to define a `AgeVerificationCredential` with whatever metadata was necessary in order to ask a third-party for age verification, and place whatever methods on that object you deemed necessary for the assertion to be obtained and delivered (with all of the security properties I'm sure you've put a lot of thought into already).
> 
> It's not clear to me what aspects of the API design prevent that from being possible.
>  
> 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.
> 
> That might be necessary and desirable for some kinds of credentials. It does not seem to be necessary for all kinds of credentials, so making it a requirement in the API seems like unnecessary complexity. If and when we decide to introduce support for such credentials, we can (easily?) define an interface that makes sense.
>  
> 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.
> 
> 1. For better or worse, schemes like BrowserID have yet to obtain wide acceptance in the market, while password are ubiquitous.
> 
> 2. Password managers make users safer in a wide variety of ways. I can enumerate advantages if you like, but I suspect we're on the same page here already, given your LastPass advocacy above.
> 
> 3. Making it easier for websites to integrate with password managers makes it more likely that users will use password managers, and obtain the advantages they provide, as long as password are still overwhelmingly used for authentication.
> 
> This seems like a reasonable goal for the short-to-medium term.
>  
> Worse, by standardizing the username/password login scheme, the spec is
> extending its lifespan, not reducing it.
> 
> Note that every mainstream browser already contains a password manager, and already does its best to help users deal with the sign-in problem.
>  
> A potential solution is to create a mechanism that takes advantage of
> some basic crypto, like BrowsrID did, to generate stronger login
> credentials.
> 
> This is a potential solution. It has the advantage of being theoretically wonderful. It has the disadvantage of requiring authors to change.
> 
> I don't think anything in the proposed API would prevent interested folks from defining a `HotNewCredential` type, and offering it to developers. In fact, standardizing a nicely generic way of requesting and storing credentials seems to be a nice way to make such a definition _easier_ for developers to find, understand, and use. 
>  
> 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?
> 
> This is a social problem which exists in the status quo. For reasons, Facebook's SDK is distinct from Twitter's SDK, which is distinct from StackExchange's OpenID implementation: sites which want to support all of these options need to include a number of different sign-in mechanisms. Nothing about this spec changes that reality. I agree it would be nice to change, but disagree that this spec makes the problem worse.
> 
> On the contrary, this spec makes it possible for a site to _meaningfully_ integrate more than one identity provider without giving their users a list of options that they can't feasibly be expected to navigate. By specifying the supported federations, and asking the user agent to match that list against the local password store, users can make a decision between those providers they already have relationships with. That seems like a nice way of mitigating some of the badness of the underlying problem.
>  
> 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".
> 
> That is a potential solution. It has the disadvantage of requiring both authors and identity providers to change.
> 
> Previous attempts to solve this problem (OAuth2, for instance) don't fill me with confidence that it's a problem we can solve in the short-to-medium term. If we do, great! We can define a `HotNewCredential` type to cover the new hotness, implement it in all browsers, and be happy together. :)
>  
> 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.).
> 
> >From a user agent implementer's perspective, I'd suggest that "login" is a very important kind of credential that every user agent I've used has built-in support for. My claim is that that support is crippled by reliance on proprietary heuristics, and can be significantly improved via an API such as the one I've proposed.
> 
> To the extent that other types of credentials are important, I'd invite you to explore the possibility of extending the proposed API with the kinds of credentials you're interested in driving support for, and getting browser vendors on board with implementing those extensions.
>  
> Here are a few of the other problems related to federated credentials in
> the spec:
> 
> I'd suggest that these more detailed concerns hop over to https://github.com/w3c/webappsec/issues/new?title=CREDENTIAL:%20 <https://github.com/w3c/webappsec/issues/new?title=CREDENTIAL:%20> for discussion, and that we keep this thread focused on the larger questions you're raising.
> 
> Thanks!
> 
> -mike
> 
> --
> Mike West <mkwst@google.com <mailto: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.)
>