Re: [webauthn] TAG review feedback: Align Credential interface with Credential Management?

On Wed, Jul 6, 2016 at 6:05 PM, Hodges, Jeff <jeff.hodges@paypal.com> wrote:

> On 7/5/16, 11:59 PM, "Vijay Bharadwaj via GitHub" <sysbot+gh@w3.org>
> wrote:
> >My understanding of the current consensus on this one is that we
> >believe this alignment no longer makes sense.
>
> we should clearly articulate why we feel this is the case and perhaps note
> it in the spec, e.g., in a design decision section. for example..
>
>   https://tools.ietf.org/html/rfc6797#appendix-A
>
> ..and also engage Mike West on the topic (cc'd)
>

Hi. :) As Jeff suggests, I think it would be reasonable to explain the
decision somewhere. The spec is probably fine, though an email recording
the decision would be useful enough as a reference.

I think it's unfortunate that y'all have decided to go in a different
direction; we talked about this a lot a ~year ago, and the Credential
Management API is significantly more generic and high-level than I actually
wanted it to be because (among other reasons) we thought the authn APIs
could be folded in. It would be helpful to understand how we failed to
build something y'all could use so that we can avoid those missteps in the
future.


> ok.  are there overall guidelines somewhere wrt what goes in which
> namespaces? (just curious...)
>

Adding things to `window` is hard, as you'll end up colliding with
variables that developers have themselves defined. `navigator` seems like a
good spot for something like this (and the credential management API) as it
represents the "identity and state of the user agent" (
https://html.spec.whatwg.org/#the-navigator-object), as well as a
conceptual holding bag for the various capabilities that the user agent
offers.


> >- Rename interface Credential to ScopedCredential to fix the name
> >collision with Credential Management.
>
> ok.
>

This still seems confusing, as it means we'll have `PasswordCredential`,
`FederatedCredential`, and `ScopedCredential`, the former two inheriting
from `SiteBoundCredential`, the latter as a standalone.

Since `ScopedCredential` itself differs from `Credential` only in the types
of the properties, it seems like we should be able to work something out.
Subclassing `Credential` into `ScopedCredential`, and adding an
`ArrayBuffer` property if you need one (though, it's not clear to me why
`ArrayBuffer` is a better choice for a platform-generated unique identifier
than a `USVString`... I'm probably misunderstanding the use-case.).

>- Possibly rename CredentialType to version to make it clearer what
> >this field signifies (since ScopedCredential is itself arguably a
> >credential type and ScopedCredentialType is unwieldy)
>
> I've been thinking about this and will fork a separate thread for it.
>

The Credential Management spec doesn't define an enum, but rather treats
`Credential::type` as a `DOMString` whose value is quasi-hard-coded in the
object via its `[[type]]` slot. Y'all might be able to get away with the
same?

-mike