RE: API consumer question: How do we recover Credential?

Regarding the IDL update to fix the dictionary/interface issue, I decided not to do this yet until we figure out the question about Credential types. Once we do that I can roll it in with the fix for #60.

Ø  [vgb] The question to you would be – do you think there is enough information in the current API so that an RP can know when it has only U2F authenticators registered, so it can do a reasonable UI?

Ø  [JCJ] I don't think there is, really. It seems that if an RP wanted to support U2F-style authenticators, it would have to supply the whitelist parameter from somewhere. It seems this becomes a choice point for RP designers: if you don't use the optional whitelist, you're limited to more advanced authenticators that remember their keys.
So couldn’t an RP tell this from the attestations? It would know which of its credentials will or will not work without the optional argument, and could do the UI accordingly.

From: J.C. Jones [mailto:jc@mozilla.com]
Sent: Friday, July 15, 2016 4:51 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: API consumer question: How do we recover Credential?

Thanks for the response, Vijay. Comments inline:

On Wed, Jul 13, 2016 at 4:47 PM, Vijay Bharadwaj <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> wrote:
Your thinking isn’t flawed at all AFAICT. These are great questions.

  1.  How do we want people to serialize/deserialize Credential objects?
You’ve hit on something that we discussed a long time ago and then just forgot about over time. The short answer is that the existing Web IDL is technically wrong.
The right way to do this is that Interface should be reserved for honest-to-goodness objects which are created by the UA and returned from various things. Input parameters should be defined as Dictionary. See http://www.w3.org/TR/api-design/#when-to-use

So to do this really truly right we would create a dictionary type with the same fields as the Credential interface, and then use JSON.parse just as you have in your sample code below. We had discussed this a long time ago but we left the IDL in the present form because it’s simpler to read and it avoids us having to explain to everyone why we have an interface and a dictionary type with the same fields. Obviously we should fix this before CR. Maybe I can roll this into the IDL update I’m doing right now as part of #84.

Good to know I'm not crazy!


  1.  For getAssertion(), whitelist is optional. But without it, how would U2F-style authenticators get their wrapped private key to do work?
They wouldn’t. This means that U2F authenticators cannot possibly do a first-factor scenario on a new device. But we knew that ••

The question to you would be – do you think there is enough information in the current API so that an RP can know when it has only U2F authenticators registered, so it can do a reasonable UI?

I don't think there is, really. It seems that if an RP wanted to support U2F-style authenticators, it would have to supply the whitelist parameter from somewhere. It seems this becomes a choice point for RP designers: if you don't use the optional whitelist, you're limited to more advanced authenticators that remember their keys.
Cheers!
J.C.