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>
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]
> *Sent:* Wednesday, March 30, 2016 7:28 AM
> *To:* Axel Nennker <Axel.Nennker@telekom.de>
> *Cc:* W3C WebAuthn WG <public-webauthn@w3.org>
> *Subject:* 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://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
>
>
>