Remove the UVM extension from WebAuthn L3 (potentially)

[timcappalli]

As far as I (and a few others I talked to) know, there are no production client implementations of the uvm extension. We should consider removing it from WebAuthn L3.

[Firehed]

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 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.

[timcappalli]

@Firehed totally understand the utility of it for RPs, but the process requires 2+ client implementations for it to remain in the spec. Since there are not, this is an issue to track its removal. This probably should have been removed before L2, but I think it was missed.

Removed features can always come back. For example, PRF was removed from L2 due to lack of implementations and is now back in L3 as the ecosystem has evolved.

[ve7jtb]

UVM has never been supported by browsers. It has the potential to have users authenticate and then have those authentications rejected by the RP with a message like "fingerprint not supported please try again using your pin."

For security keys the AAGUID will tell the RP what activation methods are supported. For phones in most cases the authenticator is using screen unlock and may not know what method is used.

RP wanting to know more about the authenticator seems reasonable for high security use cases, I just don't think UVM provides much help.

Then we run into the question of if there are enough implementations. I think it was included in L1 based on there being UAF implementations. Now I think the bar clearly needs to be WebAuthn implementations.

[emlun]

For example, PRF was removed from L2 due to lack of implementations and is now back in L3 as the ecosystem has evolved.

Not quite - it was removed due to an objection that it was out of scope and rather belongs in the Web Cryptography API. See issue #1462, issue #1478, PR #1481. My understanding is that Mozilla has since changed their position on the matter.

[timcappalli]

Ah, that's right. My mistake.