Re: Three possibilities for discussion

On Wed, Mar 30, 2016 at 10:27 AM, <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]
> *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
>