Authenticator selection extension - should makeCredential fail if no specified authenticator can be found?

[vijaybh]

In https://w3c.github.io/webauthn/#extension-authenticator-selection the current text says that if the client cannot find any willing-and-able authenticator with one of the specified AAGUIDs, then it must just go ahead and use another authenticator. However in working through use cases it seems unlikely that such an authenticator will ever be acceptable to an RP that cared deeply enough to specify this extension. Of course a client can always ignore extensions, but it seems like a client that supports this extension could provide a better UX by failing out in this case (though maybe after waiting a bit so as not to enable fingerprinting of the client).

[rlin1]

The rationale was to make sure that the user gets prompted by some authenticator in order to know that someone is trying to figure out what authenticators are present on that machine.

So this don't fail but use other authenticator was intended as a privacy features as we heardprivacy complaints about a more generic authenticator discovery feature before (which it would be in the case of returning a silent error code if the preferred authenticator is not present).

[sangraecho]

Should we have to include an extension in ClientData that indicates which authenticator is selected during the client processing?
I think this will help RP make a decision whether makeCredential operation is successful or not.

[vijaybh]

@sangraecho no, this is expected to be figured out from the attestation which does include the AAGUID. See #152 for why this cannot be in the ClientData.

[nadalin]

@gmandyam please give proposal or close

[equalsJeffH]

@gmandyam notes in webauthn f2f tpac 2017-11-09: we can close this since there is an AAGUID extension in the spec, and @gmandyam will submit some additional client extensions that address some other open issues of his.

[nadalin]

@gmandyam will submit some additional client extensions that address some of your other open issues

[emlun]

I think the privacy consideration about silent authenticator discovery is obsolete now that makeCredential, with hot-plugging, will always wait for timeout instead of failing early (#655, #687). So maybe we can let this extension fail the operation (i.e., just ignore the authenticator and keep waiting) instead of proceeding with a non-eligible authenticator.

[equalsJeffH]

on 6-Dec-2017 webauthn call: we decided this is likely overall a non-issue presently and we want to allow impls and deployments to experiment in this space and we are punting this issue to L2 such that we can re-consider after we have more experience

[equalsJeffH]

we discussed on call today and decided to close it as this seems to be a non-issue given the 1.5 yrs of experience since we re-visited it.