Here is a relevant comment from Dean Saxe (Co-chair of the FIDO Alliance Enterprise Deployment Working Group).
See also this comment in the same thread, from Tim Cappalli (of Okta, formerly Microsoft).
Finally, the FIDO Alliance webpage has a lot of information about the certification process:
Some interesting things.
Reading here: FIDO Alliance Metadata Service - FIDO Alliance
Thereās a BLOB: https://mds3.fidoalliance.org/ you can decode with: https://jwt.io/
When you decode it, you get every fido app that has a āaaguidā unique (443 of them at this time) identifier. and thereās lots of stuff in there like names, protocol, certifications, logos etc.
Next understanding is what data is sent with a passkey requestā¦and I guess depending, websites can choose if they want to accept your passkey client or not. Definitely a trip for a propellerhead only 
The AAGUID is definitely part of the passkey request.
Guess Google knows the most popular passkey clientsā¦would like to see that graph of the top 10
Iām one of those Mac mini users that doesnāt have a biometric option available, so the verification prompt for the master password does become too troublesome for my own personal adoption of passkeys.
I wonder if there could be an option like the āDevice Loginā prompt to send the verification request to another device? Not as smooth as no explicit verification, but certainly better than have to re-enter a complicated master password regularly. It would be sort of like the (now defunct) Krypton iOS app where youāre tapping to verify as a second factor.
@elasticdog Welcome to the forum!
Rest assured that the master password requirement will not be coming back after version 2024.7.1. Most likely (my best guess) is that the next implementation of user verification will allow input of a PIN or biometrics to do the verification.
Thank you all for the discussions and feedback. We are still working on designing the best path forward and will share our plans with the community when we have a proposal. Just sharing some comments after reading every post.
My personal desire is that passkeys should be joyfully easy to use, while also much more secure than todays reliance on passwords. I do not want people to type in their master password every time they sign in to a website.
A question to stay on topic, I have a question:
Whatās the downside for having only one pin, user for UV, which optionally could be used to also unlock the vault?
Iām hesitant to add multiple different pins, as every mention of a pin would need to be properly identified and understood by the user (who may be in a rush to finish their work).
Unfortunately - as per the spec - it must stay in the local perimeter of the authenticator. Sending the task to a remote device, e.g. push-based message for UV introduces a vector for phishing, just like push-based MFA does (push bombing etc, etc).
I, for one, would like to have to enter a simple pin (no more complicated than 4 or 6 numeric digits [*]) every time I use a passkey with UV. However, on certain computers, Iām not confortable with such a simple pin being able to unlock my vault.
And on those computers I still want to be able to unlock my vault with a pin, not with my master password; just a slightly more complicated pin.
Perhaps offer the user a checkbox which enables the possibility to set a FIDO UV pin different from the vault unlock one. Unchecked by default.
By the way, one thing I personally would like is not having to set that hypothetical FIDO UV pin every time I logon to my account (as I have to do with the vault unlock pin right now).
[*] Given that after 3 or 5 wrong attempts my vault locks, for example.
Preventing such a design is the whole reason for this feature request.
The UV method should be independent of the vault unlock method, because the threat models for the two uses are different, so the PIN entropy requirements will be different.
On non-mobile devices especially, the PIN is just a second password (i.e., it may contain non-numeric characters and have arbitrary length), so a security-conscious user may want a master password that is a 5-word passphrase (65 bits of entropy) and a vault unlock āPINā that is a 3-word passphrase (39 bits of entropy). This is a rational choice if the user deems the probability of a local attack to be smaller than the probability of a cloud server attack by a factor of approximately 10-8 or smaller (justifying the 26-bit reduction in entropy).
Conversely, since the passkeys are already relatively protected by being stored inside the Bitwarden vault, the entropy requirements are much lower. Once Bitwarden achieves CTAP2 compliance, an all-numeric PIN with as few as 4 digits would be permissible, and I suspect that most users would be happy with this level of added protection (13 bits of entropy). A CTAP2-compliant implementation would also need to block the passkey use once 8 incorrect PIN entry attempts have been made ā thus, a security-conscious user can follow the guidelines I have posted here to select the necessary entropy for the User Verification PIN. As shown in that analysis, a 4-digit numerical PIN (13 bits of entropy) is a very reasonable level of protection for a UV PIN ā yet this would be much too simple of a PIN for protecting a locked vault (in fact, a 4-digit numeric vault PIN can be cracked by brute force in a few seconds).
Clearly, the security requirements for the vault unlock PIN and the UV PIN are completely different, so it is essential for these to be two different PINs, independent of each other.
Perhaps make it abundantly clear to the user if the RP requires, prefers or discourages UV. This may help direct āblameā to the where it can be addressed.
In this scenario, if the user declines to validate, would it be permitted to return uv=false, but not otherwise fail the overall ceremony? The hope being to make the RP responsible for enforcing their own requirement and to be the one that must share the bad new with the user.
Would CTAP help? The introduction of its (draft) spec says:
To the first part: That would be interesting to know, yeahā¦ but I guess it would be too much information for the average user (thinking e.g. of my parents in their seventies, asking me if they have done something wrong, that a ārelying partyā ādiscouragesā āuser verificationāā¦ or somethingā¦). 
And to the second part (āblameā): I donāt know if it would make anything better to āblameā the RPsā¦ And if at all, why not take the āblameā to the FIDO alliance directly (they are mainly āresponsibleā for the passkey specs)? - Shall they all be pressurized into not requiring UV because āweā downvote it?
And as I recently wrote in another thread more or less: I would be at peace with a UV PIN or something like that, as it is a kind of ātradeā: we get rid of e.g. the inconveniency of TOTP codes but get the new inconveniency of a (possibly) UV PIN for stored passkeys.
And I still think, those security-oriented people who even donāt store their TOTP seeds in Bitwarden, will want to have UV for their passkeysā¦
I expressed this particular thought perhaps more clearly earlier in this conversation:
Perhaps āblameā was too strong a word. The Alliance is not wrong for making required a possibility. It is the RP (website) that chose to set the required flag and therefore, I feel it is their responsibility to respond to the user that wants to know why. Plus, it gives the website an opportunity to respond more gracefully, such as access to only the less sensitive portions of the web site or to prompt the user for a different form of MFA.
I already provided one perspective here, but I would like to point out an additional major problem of re-using the vault unlock PIN as the user verification PIN:
By design, the vault unlock PIN is not synced between devices, which makes sense ā security requirements for a desktop PC with restricted access in a locked office are going to be very different from the security requirements for a laptop or mobile device, which would have higher risk of theft or loss.
In contrast, the most logical and user-friendly implementation of User Verification PINs is that the UV PIN should be synced, so that the PIN that is used for performing the UV gesture during a passkey authentication ceremony will be consistent no matter which device is being used.
Again, this is yet another example of the fact that the requirements for a vault unlock PIN are fundamentally different from the requirements of a passkey UV PIN, and that confounding the two would be a flawed design.
Perhaps you could give users an option to use a single PIN for both functions, but if so, it would be essential for users to be able to disable such an option and keep the two PINs decoupled (for reasons explained here and in my previous response).
I would also like to point out that the ability to sync UV PINs is more of a āwish-listā feature that could be developed and implemented at some point in the future, as long as the near-term implementation of UV PINs does adhere to the premise advocated here ā i.e., keeping the UV PIN as a separate PIN, independent of the vault unlock PIN.
Finally, I would like to point to this exchange that I recently had with @Micah_Edelblut. The upshot is that if a separate UV PIN is implemented (which is essentially what is being requested in this thread), then that new PIN could be leveraged to fulfill other functions unrelated to vault unlocking ā for example, it could also be used as a PIN for protecting individual vault items (as an alternative to master password re-prompt).
I think that this is an excellent suggestion, and I hope that developers will see it and give it due consideration. 
This is the only way for Bitwarden to remain standards-compliant, while also accommodating users who are adamant about not performing any kind of User Verification gesture.
I believe that if such a feature is implemented (UV opt-out, resulting in Bitwardenās passkey authenticator returning uv=false), users who do choose to opt out will eventually opt back in as they realize their passkeys are being rejected by websites they wish to log in to. As long as the error messages are plainly worded (e.g. āebay.com has rejected the passkey because User Verification is disabled; to use this passkey, first enable User Verification in the Bitwarden settingsā), reasonable users are less likely to react negatively (or if they do, they would know that the UV requirement comes from the RP, not from Bitwarden). Thus, although the opt-out feature may ultimately not be used by most users, I think that having such a feature would result in a smoother roll-out of the revised UV functionality (by empowering users to make their own decisions).
In the end though, the above suggestion is peripheral to the main thrust of the current feature request thread, and probably warrants its own feature request thread. 
Question for comprehension to you experts: If the user doesnāt validate and UV=false getās send to RPā¦ you get the responsibility to the RP to tolerate that or notā¦ but wouldnāt this for the authenticator mean, to give access to the private key - and is this really in the specs or the common interpretation of ācomplianceā?
And from a practical view - if I get it right: the user would have to read and āthinkā with every authentication, how to do it this time - some can be validated, because they require it, and some donāt have to be validated, but couldā¦ I donāt want to dismiss the suggestion completely - but wouldnāt this create new chaos? (that the average user would have a hard time to understand )
No ā at least the way I see it, the suggestion is to provide an option in the app/extension settings to the effect āAllow passkey authentication to request user verificationā. I user would have the option to disable this option, after which they would never be presented by a user verification prompt (until they re-enable the option in the settings).
But again, this is unrelated to the current feature request thread. If discussion around this new proposal continues, Iād be happy to move the posts into a separate feature request.
The āaverage userā would likely just comply ā especially those that do not want chaos. The adamant user can accept any amount of chaos they want.
I was envisioning nothing more complicated than a ācontinue without verificationā button at UV validation time. You hit the nail on the head regarding the adamant userās journey. Despite that we can predict their destination, they need to take the journey to gain knowledge. And, bonus, when the adamant personās complaint reaches the correct department, the RP might just reconsider if/when they truly need ārequiredā.
Not a big fan of bifurcating conversations. It really messes with the ability to follow along and to review historic context. It is clear that āMake Passkeys betterā is on Bitwardenās radar and they are listening to our ramblings. That is much more important than the vote count, especially given that this topic, with 26 votes is in 206th place.
We are indeed listening.
Thank you everyone for providing this feedback.
While this something we consider for when the RP requests UV=preferred, the spec does not allow it when UV=required.
Edit: And while we consider it for preferred, Iām not sure it will be a UX win, as RPās are expected to fall back to doing some other kind of UV operation, like TOTP to satisfy their risk signals when UV = False.
The part of the specification (for UV=required) that you linked says:
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.
(emphasis added)
Thus, it seems that the specifications do in fact allow for the possibility of an authenticator to return a response that ādoes not have the UV flag setā when UV cannot be performed, even (or especially) when UV=required (and in this case, the onus is on the WebAuthn client to return an error). Thus, returning flags = xxxxx0xx (i.e., flags & 0b11111011) for Bitwarden users who opt out of UV should be a standards-compliant behavior.
But, as Iāve said previously, such an implementation would primarily serve as an attempt to temporarily placate some subset of users by helping them understand why UV is necessary if they want their passkeys to work. It is not, in my opinion, an important consideration, and it is tangential to the actual request proposed in this thread:
Please create a UV PIN that is distinct from the vault unlock PIN (and that will at least be compatible with implementation UV PIN synchronization, possibly in a later feature development).