- From: Eric Stern via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 May 2024 23:13:49 +0000
- To: public-webauthn@w3.org
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