Reflect caching of user verification in WebAuthn assertion

[rlin1]

Proposed Change

Some pluggable passkey providers, do not request a fresh user verification for each call to getAssertion.
This is a deviation from the traditional behavior and might surprise relying parties that are using WebAuthn today with the respective default passkey providers.

We propose the following:
a) an ability for the RP to tell the passkey provider that caching of the user verification is allowed (up to a defined time, the maximum user verification caching time maxUVC)
b) an ability for the authenticator to reflect the caching of the user verification in the assertion.

See PR #2021

[Firstyear]

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.

[ve7jtb]

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

[Firstyear]

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.

[sbweeden]

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.

[Firstyear]

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

[MasterKale]

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.

[nicksteele]

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.