webauthn
webauthn copied to clipboard
w3c
Acceptable UV caching time affordance extension added
The current behavior of some Passkey Providers to “cache” the user verification status cannot be modeled in FIDO/WebAuthn today and hence might surprise relying parties.
This PR adds the user verification extension that allows the RP to indicate its willingness to accept cached user verification for a given time.
@rlin1 we talked about this extensively at the WebAuthn F2F last year. The direction we were discussing was adding an ability for an authenticator to convey when it last performed UV and the authenticator would be truthful in its UV response in authData. This would provide the balance of an RP knowing the UV response is truthful along with some additional context, and the client and/or provider being able to make the best decision based on context they know.
This extension could potentially be part of that solution, but it is unclear whether the authenticator would reply truthfully about UV for the assertion or would lie based on the caching being acceptable to the RP.
With this approach, the maxUVC included in the authenticator output could be defined differently to be less or equal to the maxUVC as provided by the RP - so that the authenticator could set it to the elapsed time. The Authenticator today already indicates whether UV was performed. The current expectation is that this is fresh user verification. I think it would be good to let the RP indicate whether UV caching is acceptable for the specific use case.
Should this extension cover userPresence as well? If yes: we might want to rename it to userGestureCaching...
I force-pushed the branch to remove some unrelated whitespace changes from the commit history; you may need to hard-reset any local clones to the new HEAD commit.
I'm largely good with this one, as long as it is restricted for use with UV=preferred, similar to #2052.
I've been convinced that this proposal enables RP's to gracefully handle more use cases than the simpler reporting mechanism proposed in #2052. I'd say let's try and get this one into the spec instead.
I'd also add that one of the two open questions for #2052 also applies here:
Technically an out of band vault unlock for passkey provider doesn't satisfy user verification as it was not part of a WebAuthn ceremony. How do we want to handle that?
2024-04-19 WebAuthn F2F meeting: consensus to put this PR (and its alternative #2052) on hold until some details around attestation and conformance in FIDO are ironed out.
Closed due to reasons mentioned in #2034 but could revisit in the future
