RE: Three possibilities for discussion

Someone else also recently mentioned the third item on Richard’s list – that the pattern for web APIs is to put all optional arguments in a dictionary. I’ve created a issue #84 in Github so we don’t lose track of this one.

From: Alexei Czeskis [mailto:aczeskis@google.com]
Sent: Saturday, May 07, 2016 8:40 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: Richard Barnes <rbarnes@mozilla.com>; Axel Nennker <Axel.Nennker@telekom.de>; W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: Three possibilities for discussion

+1 to what Vijay said.  Keeping them separate seems like the right approach to me.


Thanks!
-Alexei


________________

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 .

On Wed, Mar 30, 2016 at 9:22 AM, Vijay Bharadwaj <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> wrote:
We’ve certainly discussed this before as well.

The problem is that makeCredential and getAssertion are conceptually quite different and typically embedded in very different UX flows.

-          makeCredential is used to generate and register a credential with an RP, typically after some out-of-band (often relatively high-friction) proofing such as phone calls, text messages, etc.

-          getAssertion is used to show possession of an already-proofed-and-registered credential, and is typically part of a very streamlined flow.

It also seems to make very little sense to sign an assertion with a credential you just created. At makeCredential time, the new credential is just a key – anyone can create one, and signing with a key you created is no feat. The RP’s problem at that time is to assign trust to that credential using other means. Since those other means must be at least as strong (in a risk-management sense) as the credential they are endorsing, they should also be enough for any purpose that would otherwise accept the results of getAssertion.

From: Richard Barnes [mailto:rbarnes@mozilla.com<mailto:rbarnes@mozilla.com>]
Sent: Wednesday, March 30, 2016 7:28 AM
To: Axel Nennker <Axel.Nennker@telekom.de<mailto:Axel.Nennker@telekom.de>>
Cc: W3C WebAuthn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Subject: Re: Three possibilities for discussion



On Wed, Mar 30, 2016 at 10:27 AM, <Axel.Nennker@telekom.de<mailto:Axel.Nennker@telekom.de>> wrote:
And then name the folded method “get” and place it into navigator.credentials ?

I'm flexible on naming.  Using signAssertion might be more descriptive.  I admit that it does take us farther from Credential API.


If there is no key already then is the method returning the results of both methods? That is: is the newly generated key immediately used to sign a challenge?

That's what I was thinking, yes.



From: Richard Barnes [mailto:rbarnes@mozilla.com<mailto:rbarnes@mozilla.com>]
Sent: Mittwoch, 30. März 2016 15:24
To: W3C WebAuthn WG
Subject: Three possibilities for discussion

Hey all,

I was hacking on a U2F stack over the weekend, and a couple of possible simplifications to WebAuthn occurred to me:

1. Fold makeCredential into signAssertionn

It seems like there's a pretty high degree of overlap between the makeCredential and signAssertion methods.  They have the following things in common:

- A challenge (attestationChallenge / assertionChallenge)
- A timeout (credentialTimeoutSeconds / assertionTimeoutSeconds)
- A list of keys the JS already has (blacklist / whitelist)
- A list of extensions (credentialExtensions / assertionExtensions)

Can we fold the semantics of makeCredential into a slightly expanded signAssertion?

OLD: Sign with one of the keys on the whitelist
NEW: Sign with one of the keys on the whitelist or generate one if you can't find a whitelisted one

This would require some additional optional stuff, e.g., to pass in the accountInformation / cryptoParameters and return the key that was generated in that case.

Basically, ISTM that people are rarely going to just call makeCredential, without calling signAssertion immediately after, so there's not a whole lot of reason for all the duplication.


2. Make Account optional

Right now, you always have to provide an Account dictionary in makeCredential.  This dictionary is just a bunch of metadata that won't apply in a bunch of cases, so we shouldn't make people put {} in there all the time.


3. Move optional parameters and extensions into an "options" dictionary

The "extensions" pattern in the WebAuthn methods seems uncharacteristic for a Web API. It's more common to package all of the optional arguments (plus any possible future ones) into an "options" dictionary.  See, for example:

https://w3c.github.io/webrtc-pc/#interface-definition<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw3c.github.io%2fwebrtc-pc%2f%23interface-definition&data=01%7c01%7cvijaybh%40microsoft.com%7c2d5ffba9b417491642ce08d358a7be3b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZlBZTH9Czuy9JrveESCCwRjD3scv75LpNZ5cxRlrHfg%3d>
https://dev.w3.org/geo/api/spec-source.html#api_description<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdev.w3.org%2fgeo%2fapi%2fspec-source.html%23api_description&data=01%7c01%7cvijaybh%40microsoft.com%7c2d5ffba9b417491642ce08d358a7be3b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AN3G0%2fmePxLpfCigZXUKDXlQPZcbS0upEYyxk2ot27Y%3d>

We should take all the optional stuff in these methods (timeout, whitelist/blacklist) and put them in an optional options dictionary which is the last argument to the method.

And as your reward for reading this far:
http://memedad.com/memes/846718.jpg<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmemedad.com%2fmemes%2f846718.jpg&data=01%7c01%7cvijaybh%40microsoft.com%7c2d5ffba9b417491642ce08d358a7be3b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3FpFnpd%2fKSkShIFAQMm8pvz9KsgNIZRu9qBYAS6gr4E%3d>


Thanks,
--Richard