Add Changed Flag to UVM Entry about webauthn

[ve7jtb]

To this point platforms have not been interested in implementing UVM or UVI. Unless there are at least two browser vendors interested in implementing this it won't survive W3C review to make it into the Level 3 recommendation.

With multi device passkey issues where the credential can be shared between devices with different biometrics and or Pins perhaps used by different family members. We also now have credential sharing between user accounts.

If there is hesitation around DPK creating friction by causing step up when using a credential on a new device, then RP asking users to step up if they register a second finger on their phone or change the pin is probably not going to be popular with people looking to reduce friction for mass market acceptance.

I think you are going to need to argue use cases. We all ready have technical solutions. You are going to need to argue why they or alternatives should be implemented.

Outing something in the spec that is not deployed just causes confusion.

I do understand why things like financial services may want this.

Regards
John B.

[ve7jtb]

There is a requirement for a minimum number of browsers ti implement a feature/extension for it to be published in a W3C recommendation. The reason those extensions were removed was that there were not the required number of browser implementations. If they had not been removed it would have held up publication of L2. Unless several independent browser implementations demonstrate support in code them they will not be going back in.

The IANA registry lists extensions published outside of the W3C such as the ones in the CTAP2 specifications. There have also been vendor specific extensions by Microsoft as an example, that were not part of a specification.

The IANA registry is to prevent name conflicts and has different rules compared to W3C recommendations.

John B.

[Kieun]

There were similar requirements from some RPs. I'm thinking that this is not just for biometric templates changes but for general user verifications information changes. Currently, WebAuthn is somehow vague about the validity of the credential if the bounded user verification information is changed after the credential is created.

[emlun]

This sounds to me like the use case for the uvi extension, which would return a unique ID identifying which user verification record was used (but not directly conveying biometric data, for example).

[ranjivaprasadvisa]

@emlun. I agree that UVI would meet the requirement. It is present in L1 of the spec but I don't see it in L2.

https://www.w3.org/TR/webauthn-2/#sctn-defined-extensions

Why did it drop out? Is it for reasons that @ve7jtb alluded i.e. no platform is implementing it.

It appears to me that the UVI should be added to the UVMEntry. Very simple then for an RP to check whether the UVM changed between credential creation and subsequent usage.

I have noticed that the L1 spec contained a large number of extensions. L2 and L3 draft have much fewer. Extensions not supported should be dropped. But @ve7jtb, UVM is there and so there is an opportunity to make it more useful to certain RPs. For certain highly regulated use cases, it is important for the RP to be in control of the experience as much as the platform. The end user expects it. An extension is a great mechanism to allow certain RPs to opt in to a different type of experience for their use cases.

UVMEntry with a UVI would allow WebAuthn to support a wider range of use cases and so in my view, make platforms more likely to implement it because it increases their utility i.e. end users can do many more things than before

[Kieun]

@ranjivaprasadvisa In case of platform authenticator, there is no such (standard native) API to return user verification index.
For two major platforms, it only tells you that the template was changed or added after you bound the key to the biometrics.
For security keys, it would be possible to provide such information, but without supports from the browsers, it would not work.

[emlun]

The uvi extension (along with several others) was indeed removed from L2 and L3 of the spec, and indeed due of lack of implementations. But they are all still registered in the authoritative IANA registry, so there's nothing stopping clients and authenticators from implementing support for them. But extensions are by design optional to implement, so we cannot in this spec mandate that clients or authenticators implement them.

[ranjivaprasadvisa]

@emlun Given that the UVI and UVM extensions are the IANA registry, I would recommend that they be added back into the L3 spec. Continuing to leave them out of the spec creates confusion i.e. if they exist in IANA then why are they not listed in a W3C spec. If I was an authenticator, I would be wary of implementing something in IANA but not in the spec because I would question how committed that WG is to that feature.

So it should be in IANA and the spec, or in neither. I agree it should be an extension though. Although I understand that no platforms have implemented to date that situation could also change, as organisations such as myself bring new use cases to the WG.

The presence of the extensions in IANA appears to indicate a commitment by the WebAuthn WG to support those extensions. That commitment should be formalised in the spec, even if there are currently no implmentations. This is consistent with the use of the term extension. We don’t expect every authenticator to implement them.

I also think that the UVI and UVM extensions should be combined. The UVI extension delivers meta-data on the UVM used and so could easily be included in the UVM extension. I can’t see why UVI would be used without UVM, or at the very least there is some overlap between both which justifies a rationalisation

[nicksteele]

After discussion on the WebAuthn weekly call on June 28th and more discussion on August 16 call, there remains little interest from browser vendors regarding implementation of UVM. If there is still interest in seeing this, I'd recommend opening an issue to discuss adding UVM (or UVI) in level 3 and then referencing this issue.