Webauthn: Pre-registration discovery for roaming authenticators

[skylerberg]

The use-case I am imagining is a registration page that supports webauthn or password credentials. I would like to display webauthn as the primary option if and only if an authenticator is present. Otherwise, I would like to display password registration primarily and webauthn secondarily.

In this scenario, I would like to know if an authenticator is present regardless of whether or not it is a platform authenticator. As far as I can tell, only platform authenticators have an API method to determine availability.

Pre-registration discovery was discussed in #503 but was ultimately closed by merging the platform authenticator availability method. #345 was closed by the same.

I considered that roaming authenticators are may be left out because of the hot-plug feature. However, in my example, I would want to primarily offer webauthn if a roaming authenticator was already plugged in and accommodate the hot-plug scenario by offering webauthn as a secondary option if no authenticators are available.

The main barrier I see to this is privacy concerns. Missing this usability feature seems like we are making webauthn harder to use and not gaining a significant amount of privacy. In #764, one suggestion was to check timing to determine availability, which sounds like exploiting a privacy issue to approximate a feature that we can't include because of privacy concerns. Furthermore, we already have a method that exposes availability of platform authenticators. Based on https://github.com/w3c/webauthn/pull/904, it appears we are considering it okay from a privacy perspective to show that there is some anonymous authenticator.

In conclusion, since a full implementation of the suggested method willMakeCredentialWorkWithTheseConstraints from #345 seems off the table because of privacy concern, can we get a isThereAnAuthenticator type method instead?

Please let me know if I got any of the terminology wrong. I am just starting to dig into this spec and would love to be corrected.

[selfissued]

I can't tell what precise text change is being proposed. A PR proposing specific changes would help reviewers evaluate this proposal.

[equalsJeffH]

see also #575

[jcjones]

This is similar to #904 in that it provides guidance to websites, but unlike #904 the data being asked for here isn't derivable by user agent matching. (isUserVerifyingPlatformAuthenticatorAvailable mostly is keeping people from hard-coding that certain versions of Windows or Android have built-in platform authenticators) This information would be a Boolean of "does the User Agent believe that this user is likely to be able to complete a WebAuthn transaction", which would be a new fingerprinting Boolean.

As a fingerprint, this would be pretty powerful: It succinctly identifies security-conscious users. I would find that very helpful if I was deciding whether to download and run a malicious script, for example. Certainly if this were set, I might not want to try and phish a user, as the phishing might run into a strong 2FA mechanism.

Our normal approach to a powerful fingerprint like this would be to make it per-origin, but that would largely defeat the purpose of the change, as it would then be doable using cookies.

Note: Tor Browser would want to be able to lie about this, and perhaps also Incognito / Private Browsing modes. They'd need to lie with the majority to not identify those modes or browsers, so application developers would need to offer a way to get into a WebAuthn flow even if isThereAnAuthenticator returns False.

Implementation thoughts

I certainly see the value of what this issue is asking for. Just to get into the implementation weeds a bit, in Firefox we could implement this two ways:

1) We set a bit if the user's profile has ever completed a WebAuthn transaction (make credential or get assertion). When isThereAnAuthenticator is called, we return that bit.

Pro: It's simple to implement.
Con: It would return False at least once, even if a security key were plugged in.

2) We monitor USB HID for a compatible security key. If one is ever detected, we set a bit in the user's profile. When isThereAnAuthenticator is called, we return that bit.

Pro: It corrects the situation where we return False when it's demonstrable that a security key is connected.
Con: It requires a periodic check of the USB bus, which is currently not monitored in Firefox except during WebAuthn transactions. It also doesn't map well to wireless security keys, which would still be False until actually used.

[emlun]

Thanks for the detailed analysis, @jcjones. Does that mean we should close this?

[skylerberg]

I am closing this due to the privacy concerns. Thank you everyone for the detailed explanations of what the issues with this feature would be. This is my first time weighing in on a web standard in any way, and I am pleased that the environment is quite open and welcoming.