Acceptable UV caching time affordance extension added #2021

rlin1 · 2024-02-12T12:44:09Z

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.

Preview | Diff

timcappalli · 2024-02-12T15:25:48Z

@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.

rlin1 · 2024-02-12T18:43:53Z

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.

rlin1 · 2024-02-14T10:46:44Z

Close #2023

rlin1 · 2024-02-14T11:34:27Z

Should this extension cover userPresence as well? If yes: we might want to rename it to userGestureCaching...

index.bs

emlun · 2024-02-14T19:42:09Z

index.bs

+  "RFC9052": {
+    "authors": ["Jim Schaad"],
+    "title": "CBOR Object Signing and Encryption (COSE): Structures and Process",
+    "href": "https://datatracker.ietf.org/doc/rfc9052/",
+    "status": "IETF Internet Standard",
+    "date": "August 2022"
+  },
+
+  "RFC9053": {
+    "authors": ["Jim Schaad"],
+    "title": "CBOR Object Signing and Encryption (COSE): Initial Algorithms",
+    "href": "https://datatracker.ietf.org/doc/rfc9053/",
+    "status": "RFC Informational",
+    "date": "August 2022"
+  },
+


These don't seem to be referenced anywhere in the added text; was this added by mistake?

was required to make bikeshed run successfully

How are you running Bikeshed? You may need to run bikeshed update to update your snapshot of the bibliography index.

index.bs

…passkey providers

emlun · 2024-03-19T21:57:07Z

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.

emlun · 2024-03-19T21:57:56Z

index.bs

+:: The maxTimeSinceLastUV denotes the maximum acceptable number of milliseconds elapsed since the last time the user was successfully verified.
+    <xmp class="idl">
+    partial dictionary AuthenticationExtensionsClientInputs {
+      unsigned long long maxTimeSinceLastUV;


This member name needs to be the same as the extension identifier.

Suggested change

unsigned long long maxTimeSinceLastUV;

unsigned long long userVerificationCaching;

should long be there twice? I guess it needs to be if we're not going to bound it.

Yes, unsigned long long is the WebIDL type for a 64-bit integer.

...oh, I was about to say we use the same type for timeout, but it turns out it's just unsigned long (32-bit). So yeah, let's make it just unsigned long here too for consistency. 2⁶⁴ milliseconds is almost 50 days, I can't imagine anyone needing more range than that.

emlun · 2024-03-19T21:58:09Z

index.bs

+:: Returns the number of milliseconds elapsed since the last time the user was successfully verified as returned by the [=authenticator=].
+    <xmp class="idl">
+    partial dictionary AuthenticationExtensionsClientOutputs {
+      unsigned long long timeSinceLastUV;


This member name needs to be the same as the extension identifier.

Suggested change

unsigned long long timeSinceLastUV;

unsigned long long userVerificationCaching;

emlun · 2024-03-19T21:58:21Z

index.bs

+
+    ```
+    $$extensionInput //= (
+      mtslUV: uint .size 4


This member name needs to be the same as the extension identifier.

Suggested change

mtslUV: uint .size 4

userVerificationCaching: uint .size 4

emlun · 2024-03-19T21:58:37Z

index.bs

+
+    ```
+    $$extensionOutput //= (
+      tslUV: uint .size 4


This member name needs to be the same as the extension identifier.

Suggested change

tslUV: uint .size 4

userVerificationCaching: uint .size 4

sbweeden · 2024-03-20T19:10:01Z

index.bs

+:: When user verification is requested, the [=authenticator=] triggers user verification only if more milliseconds have elapsed since the last time the user was verified than indicated by the maxTimeSinceLastUV value in the extension.
+
+: Authenticator extension output
+:: If no fresh user verification needed to be triggered triggered, the authenticator reports the time last last user verification time back to the [=[RP]=] to ensure the [=[RP]=] is aware that no fresh user verification was triggered.  It is up to the authenticator to decide whether to return the real elapsed time, or a "rounded" value. If user verification was requested, this value SHALL not exceed the value originally provided in the extension input.


What is the extension output if UV is done as part of the current ceremony? I know that the UV bit should be set in authenticatorData, but should the extension output also be set with a value of 0 perhaps? The purpose of returning that is to at least indicate to the RP that the extension was acknowledge and processed. The RP could infer that UV was done, but might otherwise not have been if the maxTimeSinceLastUV had been shorter. This would differentiate it from an authenticator that doesn't support the extension and just did UV because it always does UV when preferred is set for userVerification in the initial authentication request.

To be clear, the suggestion here is that extension output should be set to 0 if UV takes place during the ceremony? Which naturally means the extension output should never be greater than the duration specified as maxTimeSinceLastUV. That sounds sensible to me.

timcappalli · 2024-03-27T20:05:43Z

I'm largely good with this one, as long as it is restricted for use with UV=preferred, similar to #2052.

MasterKale · 2024-03-27T20:22:10Z

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.

timcappalli · 2024-03-27T20:39:01Z

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?

timcappalli · 2024-03-27T20:47:31Z

index.bs

+: Extension identifier
+:: `userVerificationCaching`
+
+: Operation applicability


This is where the user verification selection criteria should go IMO.

Also shouldn't this apply to both creation and authentication?

If so, suggest the following:

: Operation applicability :: [=registration extension|Registration=] and [=authentication extension|Authentication=] when {{AuthenticatorSelectionCriteria/userVerification}} is set to {{UserVerificationRequirement/preferred}}.

timcappalli · 2024-03-27T20:47:52Z

index.bs

+:: The maxTimeSinceLastUV denotes the maximum acceptable number of milliseconds elapsed since the last time the user was successfully verified.
+    <xmp class="idl">
+    partial dictionary AuthenticationExtensionsClientInputs {
+      unsigned long long maxTimeSinceLastUV;


should long be there twice? I guess it needs to be if we're not going to bound it.

timcappalli · 2024-03-27T21:12:22Z

index.bs

+:: [=authentication extension|authentication=]
+
+: Client extension input
+:: The maxTimeSinceLastUV denotes the maximum acceptable number of milliseconds elapsed since the last time the user was successfully verified.


Should we bound this with a min and max? (#2034 (comment))

timcappalli · 2024-03-27T21:13:01Z

index.bs

+:: None, except creating the [=authenticator extension input=] from the client extension input.
+
+: Client extension output
+:: Returns the number of milliseconds elapsed since the last time the user was successfully verified as returned by the [=authenticator=].


s/verified as/verified, as

timcappalli · 2024-03-27T21:14:25Z

index.bs

+    ```
+
+: Authenticator extension processing
+:: When user verification is requested, the [=authenticator=] triggers user verification only if more milliseconds have elapsed since the last time the user was verified than indicated by the maxTimeSinceLastUV value in the extension.


"If more milliseconds have elapsed since the last time the user was verified than indicated by the maxTimeSinceLastUV value in the extension, request [=user verification=]."

Firstyear · 2024-03-27T23:41:33Z

index.bs

+    </xmp>
+
+: Authenticator extension input
+:: The maximum acceptable time in milliseconds elapsed since last user verification, encoded in CBOR.


What's missing here is the negative case - if this extension is not present, do not allow caching at all. This needs to be clearly stated in the spec.

timcappalli · 2024-04-19T21:04:54Z

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.

rlin1 self-assigned this Feb 12, 2024

rlin1 requested a review from timcappalli February 12, 2024 18:44

yackermann changed the title ~~user verification caching etension added~~ user verification caching extension added Feb 13, 2024

rlin1 mentioned this pull request Feb 14, 2024

Reflect caching of user gestures in WebAuthn assertion #2023

Open

rlin1 linked an issue Feb 14, 2024 that may be closed by this pull request

Reflect caching of user gestures in WebAuthn assertion #2023

Open

emlun self-requested a review February 14, 2024 19:18

nadalin added the type:technical label Feb 14, 2024

nadalin requested a review from agl February 14, 2024 19:21

nadalin added the @Risk Items that are at risk for L3 label Feb 14, 2024

emlun requested changes Feb 14, 2024

View reviewed changes

nadalin added this to the Futures (catch-all) milestone Feb 14, 2024

rlin1 and others added 6 commits March 19, 2024 22:49

user verification caching etension added - to model behavior of some …

9e58208

…passkey providers

added suggested changes

d2ce9ce

Fix WebIDL uint type

9b431ce

Use [RP] macro

9074475

Remove unnecessary subsection

c2c3deb

Remove unnecessary bibliography additions

a45a2b6

emlun force-pushed the userVerificationCaching branch from 89c99a8 to a45a2b6 Compare March 19, 2024 21:55

emlun requested changes Mar 19, 2024

View reviewed changes

Remove unused <dfn>

f342836

nadalin requested a review from sbweeden March 20, 2024 19:03

sbweeden mentioned this pull request Mar 20, 2024

New Authenticator Extension: Time Since UV #2034

Open

sbweeden reviewed Mar 20, 2024

View reviewed changes

rlin1 mentioned this pull request Mar 27, 2024

Adds timeSinceUv extension #2052

Open

timcappalli requested changes Mar 27, 2024

View reviewed changes

timcappalli changed the title ~~user verification caching extension added~~ Acceptable UV caching time affordance extension added Mar 27, 2024

Firstyear reviewed Mar 27, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Acceptable UV caching time affordance extension added #2021

Acceptable UV caching time affordance extension added #2021

rlin1 commented Feb 12, 2024 •

edited by pr-preview bot

timcappalli commented Feb 12, 2024

rlin1 commented Feb 12, 2024

rlin1 commented Feb 14, 2024

rlin1 commented Feb 14, 2024

emlun Feb 14, 2024

rlin1 Mar 1, 2024

emlun Mar 19, 2024

emlun commented Mar 19, 2024

emlun Mar 19, 2024

timcappalli Mar 27, 2024 •

edited

emlun Apr 2, 2024

emlun Mar 19, 2024

emlun Mar 19, 2024

emlun Mar 19, 2024

sbweeden Mar 20, 2024 •

edited

MasterKale Mar 27, 2024 •

edited

timcappalli commented Mar 27, 2024

MasterKale commented Mar 27, 2024

timcappalli commented Mar 27, 2024

timcappalli Mar 27, 2024

timcappalli Mar 27, 2024 •

edited

timcappalli Mar 27, 2024

timcappalli Mar 27, 2024

timcappalli Mar 27, 2024

Firstyear Mar 27, 2024

timcappalli commented Apr 19, 2024

	unsigned long long maxTimeSinceLastUV;
	unsigned long long userVerificationCaching;

	unsigned long long timeSinceLastUV;
	unsigned long long userVerificationCaching;

Acceptable UV caching time affordance extension added #2021

Are you sure you want to change the base?

Acceptable UV caching time affordance extension added #2021

Conversation

rlin1 commented Feb 12, 2024 • edited by pr-preview bot

timcappalli commented Feb 12, 2024

rlin1 commented Feb 12, 2024

rlin1 commented Feb 14, 2024

rlin1 commented Feb 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emlun commented Mar 19, 2024

Choose a reason for hiding this comment

timcappalli Mar 27, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbweeden Mar 20, 2024 • edited

Choose a reason for hiding this comment

MasterKale Mar 27, 2024 • edited

Choose a reason for hiding this comment

timcappalli commented Mar 27, 2024

MasterKale commented Mar 27, 2024

timcappalli commented Mar 27, 2024

Choose a reason for hiding this comment

timcappalli Mar 27, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timcappalli commented Apr 19, 2024

rlin1 commented Feb 12, 2024 •

edited by pr-preview bot

timcappalli Mar 27, 2024 •

edited

sbweeden Mar 20, 2024 •

edited

MasterKale Mar 27, 2024 •

edited

timcappalli Mar 27, 2024 •

edited