search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.19k stars 172 forks source link

Reflect caching of user verification in WebAuthn assertion #2023

Open rlin1 opened 9 months ago

rlin1 commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

MasterKale commented 8 months ago

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 commented 8 months ago

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.