I'm not sure this is needed? If you have attestation then you'll know what the credential model is and will allow or disallow UP/UV caching. I can't really see a case where a deployment would want this because they either don't do attestation, so credentials are a free-for-all, or they do do attestation and they have strict policy about what credentials are or are not accepted and the properties of those devices.

The current passkey provider requirements explicitly disallow UV caching.
: Requirement 6.7
:: The UV bit in the response to either a get() or create() request MUST reflect whether user verification was performed during the processing of the request. (I.e. “caching” of user verification is not sufficient to set the UV bit in a response.)

I'm sure that it will then shock you to learn about passkey providers that set UV=true when they do not infact re-validate the user. They already do UV caching.

Ergo my point still stands - if you care about UV being a strong assertion, you need to attest credentials.

True from an enforcement-of-policy perspective but understand the point of efforts like this is to make it easier and less of a penalty for passkey providers to tell the truth.

Theres no penalty for them to lie either. Who's checking and regulating any of this?

Theres no penalty for them to lie either. Who's checking and regulating any of this?

No one now but it could become a factor in receiving e.g. FIDO certification.

It will most likely be a factor for certification and while we at 1Password will eventually become conformant regardless, that would probably be the fastest driver for us and other credential providers.