RE: Review PR 378, 428, 429

I think that #429, which puts all the authenticator selection syntax in one dictionary, is the clean way to do this.  I'm going to focus my efforts for the use cases that need resident key storage on #429.  If people agree, then we can close #378 and #428 soonish.

Have a good weekend, everyone!

                                                       -- Mike

From: Angelo Liao [mailto:huliao@microsoft.com]
Sent: Friday, April 28, 2017 4:30 PM
To: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: RE: Review PR 378, 428, 429

Following discussion last Wednesday, I added two more PRs related to requireResidentKey, which represents three different approaches:


  1.  PR 378<https://github.com/w3c/webauthn/pull/378>:
     *   This PR adds requireResidentKey to MakeCredentialOptions
  2.  PR 428<https://github.com/w3c/webauthn/pull/428>:
     *   This PR adds AuthenticatorSelectionCriteria dictionary to MakeCredentialOption.
     *   AuthenticatorSelectionCriteria includes requireResidentKey
  3.  PR 429<https://github.com/w3c/webauthn/pull/429>:
     *   This PR adds AuthenticatorSelectionCriteria dictionary to MakeCredentialOption (same as 2nd approach)
     *   AuthenticatorSelectionCriteria includes both Attachment and requireResidentKey

Again, to reiterate my previous point, the addition of the parameter is to enable users to log into website with external devices without entering their username. Although I added two PRs that tie the parameter with authenticator selection, I really don't see it as the same thing. I see the parameter as a way to fix a problem with logging into external device.

Angelo

From: Angelo Liao
Sent: Tuesday, April 25, 2017 4:14 PM
To: W3C WebAuthn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Subject: Review PR 378:

Hi Everyone,

I am sending a mail to remind everyone to review PR 378: Enable RP to choose authenticators based on key storage capability. <https://github.com/w3c/webauthn/pull/378> Thanks to Jeff and Vijay for reviewing the PR. My view on the PR is that the PR is really not about authenticator selection but rather a bug fix on the original API interface. Without the PR, developers who want to use "get" with only challenge would find the failure cases a lot of times.

I am perfectly happy with additional discussions about adding a framework for authenticator selection to aid user experience. But I don't think adding the framework is that closely related to this PR because this PR is to ensure developers can get users logged in smoothly based on their intent when they created the credential. That's also why the Edge team wants to ensure the PR is added. Web developers we talked to have said they cannot log users in (aka use the method "get") without having this parameter.

Angelo