Webauthn: Allow hot-plugged authenticators?

[emlun]

In discussing the Firefox implementation with @jcjones we discovered a wrinkle in the create() and get() ceremonies: Hot-plugged authenticators - yes or no?

Currently, §4.1.3. Create a new credential and §4.1.4. Use an existing credential to make an assertion both specify their procedure on the form

1. Prepare authenticator arguments
2. Let currentlyAvailableAuthenticators be a new ordered set consisting of all authenticators currently available on this platform.
3. Send command to each element of currentlyAvailableAuthenticators
4. Wait for success or timeout

This seems to imply that hot-plugging is not supported - that authenticators that become available after (2) but before (4) must be ignored. However there are multiple benefits to allowing hot-plugging:

• This is how the U2F implementations in Chrome and Firefox work, so users are accustomed to it.
• Relaxing the order of events makes for a much smoother user experience.
• It simplifies use of the JS API by making it less stateful. Without it the only way for the caller to ensure that the authenticator is ready, before calling create() or get(), is to prompt the user to ready the authenticator (i.e. plug it in) and then manually confirm this (i.e. press the "Next" button).
• The language "currently available" becomes very vague in the context of NFC, as the authenticator is necessarily "plugged in" _after_ the call to create() or get().

The main caveat is that a call to create() or get() whose excludeCredentials or allowCredentials exclude all currently available authenticators would also wait for the timeout, which may not always be wanted. But on the other hand, the vast majority of users will probably only have one authenticator anyway.

I can draft a suggestion for this if it sounds like a good idea.

[jcjones]

A very good point. Right now our WebAuthn implementation allows hotplugging... while the algorithm language is pretty clear on not allowing hotplugging.

https://github.com/w3c/webauthn/blob/0cae38154c59cf4760e7dfed00f2c44e298f8c9f/index.bs#L661-L664

Obviously we paid very close attention to the specific algorithm language! 😀

[jovasco]

For BLE authenticators, it is almost certain that the authenticators will appear somewhere during the process, whenever the user turns it on.

[equalsJeffH]

yeah, this seems to be a good point.

@jcjones

Right now our WebAuthn implementation allows hotplugging...

perhaps we ought to use your impl to inform the webauthn spec?

i wonder if we can handwave in the webauthn spec algorithms that authnrs may appear or disappear during the process ?

I wonder how one might use webIDL+HTML+infra+etal specs to model something where there is an OnAuthnrBecomesAvailable handler that can add to the available set of authnrs up to the time that one of the authnrs declares success (and vice versa, have a OnAuthnrIsRemoved handler) ?

I wonder whether we actually need to "code" these details in the spec or whether we can use "Note:"s to outline such nuances? E.g.:

The set of currentlyAvailableAuthenticators may dynamically change during this process and implementations should handle this in order to make the user experience more seamless. E.g., an NFC-connected roaming authenticator will not become "available" until the user physically taps it to their webauthn-enabled device...

[equalsJeffH]

see also issue #508 and #574

[nadalin]

@jcjones Please verify

[jcjones]

PR #655 addressed at least a portion of this issue, though this needs to remain open since two inline issues in the spec point here. The text in the spec is:

The definitions of "lifetime of" and "becomes available" are intended to represent how devices are hotplugged into (USB) or discovered by (NFC) browsers, and are under-specified. Resolving this with good definitions or some other means will be addressed by resolving Issue #613. ↵

We'll want to fix this before PR.

[equalsJeffH]

per investigating issues #204, #184, PRs #655 #687 -- i've updated @jcjones comment above with: "PR #655 addressed at least a portion of this issue, though this needs to remain open since..."

[emlun]

Re-opening this since @equalsJeffH has additional after-the-fact review comments at https://github.com/w3c/webauthn/pull/900#pullrequestreview-126523183 .