webauthn
webauthn copied to clipboard
w3c
New Authenticator Extension: Time Since UV
Proposed Change
As discussed on multiple working group calls, this would be an alternative approach to address the user verification caching concerns raised by passkey providers and relying parties.
This approach does not change the meaning or operation of user verification and authenticators would still be required to respond truthfully about UV at the time of the ceremony.
This extension, tentatively identified as timeSinceUv, will allow an authenticator to include the time since UV was performed. The value is expressed in milliseconds for consistency with the rest of the spec.
Relying Parties who want the UX benefits of UV preferred, but would like additional context for post-authentication business logic can request the extension.
Example
Request
UV = preferred
Extensions = [ timeSinceUv ]
Authenticator State User verification was performed 5 minutes ago
Response
UV = false
Extension.timeSinceUv = timeSinceUv: 300000
Some comments from 2024-02-28 WG call:
- authenticators could round to a number of significant figures to make the resolution more coarse
- introducing noise could be an option to reduce any tracking vectors (AGL shared this link: https://lbarman.ch/blog/padme/)
- requiring that the value be rounded to minutes could also potentially help
- another alternative would be to use an enum with pre-defined buckets. e.g.
[ "1m", "5m", "10m", "30m", "60m" ]
Capping a timestamp at a max value could also help with reducing fingerprinting possibilities.
There is an RP policy gap in this idea that I think could be addressed by having an extension which permits inputs and outputs. The use case is, "As an RP I'm ok with uv=preferred however only if its within the last xx period (eg an hour)".
This would then allow the authenticator the opportunity to honour the policy rather than have the RP reject it after the ceremony. The input to the extension could express the policy, the output could express the authenticator's actual behaviour.
If the input was 0, and uv=preferred, this is semantically equivalent to uv=required.
Padme is great for file sizes, where overhead is a concern. But here you can just round the delta in milliseconds up to the next power of two. I would also trim the values less than 1 second or more than 1 day. The resulting bins are:
0h 0m 1s
0h 0m 2s
0h 0m 4s
0h 0m 8s
0h 0m 16s
0h 0m 32s
0h 1m 5s
0h 2m 11s
0h 4m 22s
0h 8m 44s
0h 17m 28s
0h 34m 57s
1h 9m 54s
2h 19m 48s
4h 39m 37s
9h 19m 14s
18h 38m 28s
That's probably still more resolution than RPs need. We could round to the next even power of two to thin it out further.
I think@jschanck proposal is better than noise+caps in both simplicity and useful resolution.
There is an RP policy gap in this idea that I think could be addressed by having an extension which permits inputs and outputs. The use case is, "As an RP I'm ok with uv=preferred however only if its within the last xx period (eg an hour)".
As long as that xx period is compared to the resolution suggested by @jschanck I think we negated the privacy concern that was raised during the call and would result in better UX.
There is an RP policy gap in this idea that I think could be addressed by having an extension which permits inputs and outputs. The use case is, "As an RP I'm ok with uv=preferred however only if its within the last xx period (eg an hour)".
This would then allow the authenticator the opportunity to honour the policy rather than have the RP reject it after the ceremony. The input to the extension could express the policy, the output could express the authenticator's actual behaviour.
If the input was 0, and uv=preferred, this is semantically equivalent to uv=required.
Looks like my idea has been expressed in proposed PR #2021
From WebAuthn WG Call on 26/3/25: The 3rd party passkey providers, for which this issue was targeted, were unwilling to solve the issue in this manner, and there was little interest from the working group in pushing this work forward regardless. The problem that this was aimed at fixing still persists in some providers.
