- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Sun, 05 Nov 2023 22:41:03 +0000
- To: public-webauthn@w3.org
> This is indeed the `"preferred"` user verification option behaving as expected. Preferring user verification allows RP's to optimize the authentication user experience by signaling that browsers and passkeys providers can avoid situations in which a user might get prompted for a password. Practically it almost never works like this. Yubikeys always request a PIN. Windows hello will always ask for a PIN. So why is touchid special here? Why is it allowed to just ditch UV because it feels like it? If you have your macbook pro, and it always asks for touch id, then one day you sit at your desk and it stops, that *confuses* the user. It makes them think "wait, hang on, this always needed my fingerprint before, why can I just click continue now?". You know what real humans have said about this in my work surveying people? They quite broadly responded that it means they no longer trust that the credential needs UV at all and they lose trust in it. This undermines faith in the security of a system. What preferred *actually* causes is that during device registration it means "we accept devices that will *always* do UV, or we accept devices that can't do UV". This lets the RP make choices about the device as a whole, and it's properties it should consistently and always have going forward. This way you make policy choices about the authenticator and all future ceremonies that authenticator will be a part of. The whole "UV is part of the ceremony" line is quite silly and we need to stop it. > > Case in point: a typical user on a Mac Mini, without any kind of biometric sensor available, might wonder why they're constantly being prompted for their local login password when using a passkey for "passwordless auth". This stands to hurt passkey adoption as the use of a password, even a local-only one, can be confusing. > > I'd also suggest that with the authentication bar being raised so much higher with passkeys, maybe it's okay for user verification to sometimes be false. The ceremony still benefits from the phishing-resistant aspects of WebAuthn auth, and the majority of platforms and roaming authenticators will actually perform UV. Couldn't RP's factor in the additional MFA barriers that platform authenticator passkey providers have implemented to be okay with sometimes getting `uv:false` from ceremonies they participate in? 🤔 It's a shame that UV=discouraged here just means that you inconsistently sometimes get a PIN and sometimes don't, rather than being "never get a PIN at all, just accept UP". But that ship has well and truly sailed too. > > That said the power is in the RP's hands to avoid the ambiguity of a "preferred" ceremony if the RP doesn't like it. Mark UV "required" in options and check the auth data `uv` flag in the response - you'll more reliably get back `uv:true` as desired. Maybe the specification should reflect RP intents around device expectations having UV properties associated to the device, for the lifetime of the device. And maybe browsers shouldn't undermine user security expectations by "sometimes wanting UV and sometimes not". But at this point I think that ship has *also* sailed, and now every RP has to realistically set UV=required to ensure consistent user experience - even if that user has to type in their platform password for a passwordless credential. It's getting harder and harder for an RP to navigate this spec and how to make it usable, consistent and secure for users. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1993#issuecomment-1793869183 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 5 November 2023 22:41:05 UTC