RE: Three possibilities for discussion

And then name the folded method “get” and place it into navigator.credentials ?

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?

From: Richard Barnes [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://dev.w3.org/geo/api/spec-source.html#api_description


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



Thanks,
--Richard

Received on Wednesday, 30 March 2016 14:27:49 UTC