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 13:24:04 UTC