New Authenticator Extension: Time Since UV

[timcappalli]

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]

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]

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

[sbweeden]

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]

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]

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]

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