Re: [webauthn] Don't be so strict about uv with the PRF extension. (#1836)

> I think the stronger wording was fine because I think RP's should know there are risks of changing between the UV types, and so consistency is important.

After dabbling with `prf` last week I think I have to second this notion. Most of the hype around this extension are people wanting to implement client-side E2EE. It feels like a foot gun to leave the door open for RP's to build out functionality that sometimes fails (catastrophically, in the case of encryption) because a browser decides that `"preferred"` actually means "evaluate the non-UV prf because UV isn't configured", missing the nuance being introduced here that the UV prf should be evaluated "...if it is capable of it..."

`"preferred"` is already fraught with inconsistent behavior, as recent conversations in the WG have highlighted. Is it in our best interest to continue to encourage ambiguous implementations of WebAuthn around this value, when practically speaking UV should almost always be required or discouraged depending on the RP's authentication model?

-- 
GitHub Notification of comment by MasterKale
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1836#issuecomment-1403030608 using your GitHub account


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

Received on Wednesday, 25 January 2023 03:00:23 UTC