Re: Splitting "Credential Management"?

On Tue, Mar 21, 2017 at 7:59 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> On Fri, Mar 17, 2017 at 10:43 AM, Mike West <mkwst@google.com> wrote:
>
>> Thanks for your comments, Dominic!
>>
>> On Fri, Mar 17, 2017 at 6:27 PM, Dominic Battre <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.