Re: [webauthn] Remove the UVM extension from WebAuthn L3 (potentially) (#2069)

I know this has been discussed quite a few times in different contexts (#1890 most recently comes to mind), but this feels a little chicken-and-egg to me as far as requiring implementations goes - please forgive any of my ignorance around general W3C procedures here!

From an RP perspective, it would very valuable to be able to distinguish between not only single- and multi-factor auth coming from an assertion (already possible via `uv`), but _which_ supplemental factor type(s) was used. While not all RPs will care about this data, it can make a world of difference in high-security deployments, especially since there are different legal implications for knowledge vs biometric factors in some jurisdictions. Being able to use the `uvm` extension would allow RPs to implement a more streamlined auth flow depending on their risk model, adjust threat assessment rules, and more.

`uvm` may not necessarily be the right path here, but it seems like a good privacy-preserving approach to solving a real problem. As an RP, I'd like to have at least a ballpark-accurate view of what [IANA AMR values](https://www.iana.org/assignments/authentication-method-reference-values/authentication-method-reference-values.xhtml) might apply to the WebAuthn assertion (not necessarily in that format or level of detail, but it's a useful way to think about it).  If `uvm` is not the best way forward, I'd certainly advocate for some sort of replacement rather than dropping the idea outright.

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


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

Received on Thursday, 9 May 2024 23:13:49 UTC