Passkey User Verification Independent of Vault Unlock Method

[DenBesten]

Thank you so much for allowing us users to play a part in the design.

@andersaberg

the spec does not allow it when UV=required.

I believe the portion of the spec under debate is:

The Relying Party requires user verification for the operation and will fail the overall ceremony if the response does not have the UV flag set.

My take on this that:

1. The RP has the responsibility to declare the ceremony failed. To do this, the authenticator needs to report its findings to the RP, rather than declare failure itself.
2. Since the RP declares failure, they hold the burden of notifying the user.
3. The spec anticipates/permits “uv=false” as a response to “required”, given that the spec describes the response the RP should take.

The client MUST return an error if user verification cannot be performed.

“Return an error” is the notable bit. My view is that responding “UV=false” is precisely how an authenticator would report the error. In other words, this sentence of the spec obliges the authenticator to be truthful when setting/clearing the UV flag.

Even though I have “stated my case”, I do understand that it is Bitwarden, not me, that will be the defendant during certification. Therefore, Bitwarden’s interpretation is much more important than mine.

That said, there is a fundamental ambiguity in the spec that results in this conversation even occurring. I would greatly appreciate you requesting they dis-ambiguate the (draft) spec, perhaps by changing it to “… MUST clear the UV flag if …”

Incidentally, §1.3.3 #8 also covers this, but with no more clarity.

[grb]

@DenBesten

My view is that responding “UV=false” is precisely how an authenticator would report the error.

FYI, it is the WebAuthn client (e.g., the browser) that must return an error, not the authenticator (i.e., Bitwarden). Not “setting” the “UV flag” means that the authenticator returns a response in which the value of the flags field has its Bit #2 set to 0); when this happens, the client must return an error if the RP has specified that UV is required.

[dabura667]

I would like to throw my 2 cents in here.

I think it would be cool if the “log in with device” flow could be re-purposed for Passkey UV.

I know Chrome has a QR code + Bluetooth thing that allows you to verify for your PC using your phone’s passkeys, but if Bitwarden also had a setting to where it required you to open your Bitwarden on your smartphone and do biometrics for passkeys that would be super cool.

From the browser perspective it would just be local passkey. The QR code BLE verification can be flaky sometimes, so having an alternative via Bitwarden would be awesome… and help people without biometrics on their PC.

[Roki]

really no updates on this? pushing passkeys forward but not having such needed security feature?

[Nail1684]

@Roki Welcome to the forum!

I’m not sure for other platforms - but for Windows 11 there seems to be coming a different implementation:

Third-party passkey manager support in Windows 11

Microsoft has announced support for third-party passkey managers in Windows 11: Third-party passkey manager support - Windows apps | Microsoft Learn Does Bitwarden have plans to support this in the near term? That would be really neat, because I feel like lack syncability of passkeys across platforms is a major issue that needs to be solved for it to really take off as a viable alternative to passwords.

(as the FIDO Alliance and some “password managers” like Bitwarden, 1Password and others… and OS vendors like Microsoft… seem to collaborate here, I guess, something similar could be in the works for Apple and Linux?!?)