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

Hi Mike, and thanks for chiming in here.

Taking your questions in reverse order:


Ø  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?

Yes, this is not a big deal IMO.


Ø  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.).

The unique identifier is generated not by the platform but by the authenticator. In many cases the authenticator has no non-volatile memory, just a burned-in encryption key, so the “identifier” it returns is just the credential key pair, encrypted with this burned-in key. So it will be an arbitrary bundle of bits. We could turn this into a USVString by something like base64 encoding, but that just adds complexity for no functional gain.


Ø  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.

This is the most important question. The WebAuthn makeCredential method is very much like the CredentialManager store method if you squint a bit, but the big difference is that WebAuthn has no counterpart to the CredentialManager’s get method. You don’t get a WebAuthn credential, only a signature/assertion from it. So there is never a credential object which can be cloned in any way.

To a large extent this comes from the model of the WebAuthn authenticator as being a separate thing entirely from the client and browser – it could be a piece of hardware with its own storage and I/O capabilities. So the collection of credentials and authenticators available to a platform at any time is constantly changing for reasons having to do with the physical environment, and in some cases (think NFC) you won’t know that an authenticator/credential is there until the last moment.

Even though we started from the Credential Management model when building WebAuthn, as we worked through the developer model and the user experience issues, it made less and less sense to track the collection of WebAuthn credentials in a construct like CredentialManager. Instead WebAuthn is very transactional – essentially, every getAssertion call involves picking a credential through some interaction between user and client with some guidance from the caller.


From: Mike West [mailto:mkwst@google.com]
Sent: Wednesday, July 06, 2016 2:08 PM
To: Hodges, Jeff <jeff.hodges@paypal.com>
Cc: Vijay Bharadwaj via GitHub <sysbot+gh@w3.org>; public-webauthn@w3.org
Subject: 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<mailto:jeff.hodges@paypal.com>> wrote:
On 7/5/16, 11:59 PM, "Vijay Bharadwaj via GitHub" <sysbot+gh@w3.org<mailto:sysbot%2Bgh@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