-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Authenticator Extension: Time Since UV #2034
Comments
Some comments from 2024-02-28 WG call:
|
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:
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.
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. |
Looks like my idea has been expressed in proposed PR #2021 |
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
The text was updated successfully, but these errors were encountered: