RE: Splitting "Credential Management"?

A few comments on the statements below:

MW:“Which we should fix by making federated credentials do more work. The existing `FederatedCredential` is a stopgap result of no one having taken the time to design and implement a better solution, not an end state we actively want to maintain. It solves the NASCAR problem, barely, and that's Good Enough for a first pass, but there's tons of work to be done here.”

AL: Agreed. The current spec delegates it all out to OAuth but more work should/can be done to make the experience better. I believe Adam Dawes from Google is working on some UI studies to figure out what is the most smooth experience here.

MW: So, the current spec (and strawman PR against the WebAuthn spec) doesn't use the chooser, but just farms the request out to the authenticator device. If we can do better than that, I'd be excited to do so. :)

AL: AFAIK all browsers will have to do some kind of UI similar to the chooser for WebAuthn to allow users to choose which account/authenticator they want to use. A good number of authenticators don’t have screen capability so the only one that can offer this is the browser. It’s entirely possible for the chooser to be re-used.
JY: “password" is currently different from both "federated" and "scoped" in that its result is actually a copy of the credential instead of just a proof that the user owns the credential. (Here I'm treating "federated" as including the subsequent OAuth flow.)
AL: IMO the “copy of the credential” statement is more or less a personal taste one. One easily say password is a proof that user owns the credential by sending a copy. Plus many sites these days encrypt the password before sending it to the server.

From: Mike West [mailto:mkwst@google.com]
Sent: Wednesday, March 22, 2017 3:39 AM
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: Dominic Battre <battre@google.com>; Daniel Bates <dabates@apple.com>; public-webappsec@w3.org; Václav Brožek <vabr@google.com>; Angelo Liao <huliao@microsoft.com>; Peter Dolanjski <pdolanjski@mozilla.com>
Subject: Re: Splitting "Credential Management"?

On Tue, Mar 21, 2017 at 7:59 PM, Jeffrey Yasskin <jyasskin@google.com<mailto:jyasskin@google.com>> wrote:
On Fri, Mar 17, 2017 at 10:43 AM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
Thanks for your comments, Dominic!

On Fri, Mar 17, 2017 at 6:27 PM, Dominic Battre <battre@google.com<mailto:battre@google.com>> wrote:
- As discussed some time ago, maybe we should get rid of SiteBoundCredential and move name and iconURL into PasswordCredential and FederatedCredential.

`SiteBoundCredential` is pretty convenient as a container for the `[[Request]]` and `[[Store]]` methods that `PasswordCredential` and `FederatedCredential` alias.

That said, we could achieve the same effect by defining a single algorithm and aliasing it in both interface objects. I wouldn't be terribly sad if we got rid of `SiteBoundCredential` entirely... but then what do we name the document? :)

What is actually similar between passwords and federated credentials, which distinguishes them from "scoped" (WebAuthn/FIDO) credentials?

One distinction beyond those listed below is that the browser can make a priori decisions about whether passwords/federations are present and available. The lack of a stored authenticator binding in the UA doesn't mean that it shouldn't ask for devices to be inserted, right?

This is arguably the same for federations, though, now that I think about it.

  1.  Right now, they have a name and icon, but WebAuthn has that and a little more in the Account dictionary<https://w3c.github.io/webauthn/#dictdef-account>, so that doesn't seem like a fundamental difference.
Indeed. And I think it's reasonable to fold those into the `ScopedOrWhateverCredential`, though it's a little confusing since it relies on device capability (authenticator with a screen).

  1.  "federated" is different from both "password" and "scoped" in that only "federated" omits the proof of credential possession.
Which we should fix by making federated credentials do more work. The existing `FederatedCredential` is a stopgap result of no one having taken the time to design and implement a better solution, not an end state we actively want to maintain. It solves the NASCAR problem, barely, and that's Good Enough for a first pass, but there's tons of work to be done here.

  1.  There seems to be some notion in the current design that a site could allow the user to pick between "password" and "federated", but could not allow the user to pick between "password" and "scoped", because of some sort of UI concern. What about that pairing makes the UI difficult?
I don't think there's a fundamental UI concern. People cleverer than me could certainly find a way to express things reasonably to a user, and walk them through the series of steps necessary to hand over one or the other type.

That said, I think there's a practical concern for WebAuthn in that the way it involves the user isn't browser-based at all (the spec's declarations to the contrary). The developer calls the API, and a hardware token flashes. Everything else is up to the website to do themselves. Or a magical new authenticator pops up its own chooser dialog for all the credentials it has stored locally. I'm not sure how to mediate that conversation in the browser.

So, the current spec (and strawman PR against the WebAuthn spec) doesn't use the chooser, but just farms the request out to the authenticator device. If we can do better than that, I'd be excited to do so. :)

  1.  "password" is currently different from both "federated" and "scoped" in that it tries to defend against XSS.
With the caveat that this is being actively debated internally at Google, there's no reason we wouldn't apply equivalent protection to tokens delivered with federated credentials if/when we deliver such tokens.

  1.  "password" is currently different from both "federated" and "scoped" in that its result is actually a copy of the credential instead of just a proof that the user owns the credential. (Here I'm treating "federated" as including the subsequent OAuth flow.)
Eh. I'm a little fuzzy on this difference. There's certainly a large distinction in how the validation happens (comparison of a hash to a DB vs verification of a signed challenge), but in my mind, both cases boil down to an object we hand over to the developer for user validation.