Re: [webauthn] Should an RP be able to provide finer grained authenticator filtering in attestation options? (#1688)

I would like to add another perspective from an enterprise RP. Explaining the challenge with non tech-savvy end users related to FIDO Authenticator registration and the corresponding OS/Browser UX.

Finding the correct Authenticator registration type (ie. Platform, Security Key via Usb, Roaming Authenticator via BLE initialised via QRCode/caBLE, etc.) is not easy for a non tech-savvy end user. There are many user complaints that it is too confusing.

Generally OS/Browser UX looks different for every OS & Browser combination. Furthermore the initial screen is not always deterministic. Actually the screen which is shown initially depends on several circumstances. Sometimes it starts on the page where you have to scan the QR-Code. But if the user wants to register a security key he has to navigate back and find the correct option. That is often a challenge for most non tech-savvy users (That's only an example, there are more similar issues)

Maybe it would be easier for the user to stay as long as possible on the website during FIDO Authenticator registration until the OS/Browser UX kicks in. Because then the website has the chance to guide and help the user to find the specific Authenticator registration type. The website could describe the various options specifically targeted for the applications user audience (tech-savvy, non tech-savvy, Only Security-Keys allowed etc.) The user will experience a more streamlined UX. And only the final registration step would be executed by the OS/Browser UX.

To be clear about the requirement. It is not about limiting the options for the end user. It's about better and consistent user guidance (no authenticator discrimination).

Currently webAuthN 2 gives the opportunity to control a bit of the Browser UX via authenticatorSelection.authenticatorAttachment (cross-plattform/plattform). That's it, AFAIK.
 
Could it be useful to add Transport hints (like usb, internal, nfc etc.) as a property to authenticatorSelection? However, I am afraid that this is not enough.

How could this challenge be solved? Any further Ideas?

Cheers,
Dennis

-- 
GitHub Notification of comment by denniskniep
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1688#issuecomment-1528864591 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 29 April 2023 20:18:09 UTC