Skip to content
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

Open
timcappalli opened this issue Feb 28, 2024 · 6 comments · May be fixed by #2052
Open

New Authenticator Extension: Time Since UV #2034

timcappalli opened this issue Feb 28, 2024 · 6 comments · May be fixed by #2052
Assignees
Labels
stat:Blocked Prerequisites are not yet satisfied type:technical

Comments

@timcappalli
Copy link
Member

timcappalli commented Feb 28, 2024

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

@timcappalli
Copy link
Member Author

timcappalli commented Feb 28, 2024

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" ]

@MasterKale
Copy link
Contributor

Capping a timestamp at a max value could also help with reducing fingerprinting possibilities.

@sbweeden
Copy link
Contributor

sbweeden commented Feb 28, 2024

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.

@jschanck
Copy link

jschanck commented Feb 28, 2024

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.

@abergs
Copy link
Contributor

abergs commented Feb 29, 2024

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.

@sbweeden
Copy link
Contributor

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

@nadalin nadalin added the stat:Blocked Prerequisites are not yet satisfied label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stat:Blocked Prerequisites are not yet satisfied type:technical
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants