Re: Splitting "Credential Management"?

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?

   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.
   2. "federated" is different from both "password" and "scoped" in that
   only "federated" omits the proof of credential possession.
   3. 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?
   4. "password" is currently different from both "federated" and "scoped"
   in that it tries to defend against XSS.
   5. "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.)

Jeffrey