Adds timeSinceUv extension

[timcappalli]

Adds the timeSinceUv authenticator extension as defined in #2034

Open questions for WG discussion:

1. 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?
2. If the time since UV value is out of range (<1000 or >86400000), what should happen?

Resolves #2034

---

Preview | Diff

[rlin1]

Don't understand the overall flow.
Let's assume the RP is interested in 'fresh' user verification (i.e. timeSinceUv = 0).
With this proposal, the RP would ask for timeSinceUv extension and likely for UV=required, now assume the passkey provider returns UV=1 and timeSinceUv = 10 minutes. Then what? RP is frustrated that the security policy cannot be met, but doesn't have a practical way to ask for a fresh user verification.

According to PR #2021, the RP could tell the passkey provider that fresh user verification is required and the passkey provider would likely want to do it as that apparently is required by the RP.

[timcappalli]

@rlin1 this is only used with UV=preferred.

Spec text (line 7622): [=registration extension|Registration=] and [=authentication extension|Authentication=] when {{AuthenticatorSelectionCriteria/userVerification}} is set to {{UserVerificationRequirement/preferred}}.

If an RP wants a fresh UV and will fail or otherwise step up, they should use UV=required.

the RP could tell the passkey provider that fresh user verification is required

That is what UV=required does today.

The goal of this, as highlighted in #2034, is to not change the long standing meaning of UV in the spec.

[sbweeden]

Is this a counter-proposal to the #2021 PR? If so, I prefer the semantics of #2021 which allows the RP to specify in extension input a preferred max time since last UV such that the authenticator/platform could choose to satisfy that policy by re-prompting for UV as part of the ceremony rather than the RP rejecting an assertion because all it could do was find out the time since last UV and then deciding it wasn't recent enough.

[MasterKale]

Is this a counter-proposal to the #2021 PR? If so, I prefer the semantics of #2021 which allows the RP to specify in extension input a preferred max time since last UV such that the authenticator/platform could choose to satisfy that policy by re-prompting for UV as part of the ceremony rather than the RP rejecting an assertion because all it could do was find out the time since last UV and then deciding it wasn't recent enough.

@sbweeden I agree with you, #2021 is preferable from the RP's perspective. But going that route re-opens the can of worms that is, "add in ways to let RP's pre-fail a ceremony." Historically those proposals have gotten squashed pretty quickly in the name of maintaining user agency in these ceremonies. Should not #2021 be rejected for similar reasons? i.e. we can't let RP's fail the ceremony here if UV happened too long ago because then we'd have to allow other proposals for RP's to require more properties of a credential or authenticator be asserted by the client before the RP receives a response.

[sbweeden]

@sbweeden I agree with you, #2021 is preferable from the RP's perspective. But going that route re-opens the can of worms that is, "add in ways to let RP's pre-fail a ceremony." Historically those proposals have gotten squashed pretty quickly in the name of maintaining user agency in these ceremonies. Should not #2021 be rejected for similar reasons? i.e. we can't let RP's fail the ceremony here if UV happened too long ago because then we'd have to allow other proposals for RP's to require more properties of a credential or authenticator be asserted by the client before the RP receives a response.

Assuming this was a user privacy concern, I don't think a UV recency policy is a privacy concern, nor does it imply that an RP can pre-fail a ceremony since all (non-U2F) authenticators should support UV in some way. It's simply the RP saying that UV caching has its acceptable limits, and this is what they are, such that the client+authenticator can choose to satisfy them without the RP failing the assertion post-ceremony.

[timcappalli]

rather than the RP rejecting an assertion because all it could do was find out the time since last UV and then deciding it wasn't recent enough

@sbweeden By requesting UV=preferred, you are stating that you will accept an assertion without user verification.

If you will fail the login ceremony completely without UV, you should use UV=required.

If you are OK with no UV, but need additional context for a risk engine (which may or may not ask for additional information), then you can use UV=preferred with this extension.

[sbweeden]

rather than the RP rejecting an assertion because all it could do was find out the time since last UV and then deciding it wasn't recent enough

@sbweeden By requesting UV=preferred, you are stating that you will accept an assertion without user verification.

If you will fail the login ceremony completely without UV, you should use UV=required.

If you are OK with no UV, but need additional context for a risk engine (which may or may not ask for additional information), then you can use UV=preferred with this extension.

This extension does not afford the opportunity for the client+authenticator to prompt for UV, as part of the ceremony, only if the time since last UV doesn't satisfy the RPs policy. That's the use case that #2021 covers, that this extension does not.

[timcappalli]

Correct. That wasn't in scope for the proposal (#2034)

[emlun]

I too don't quite understand what use case this would address that isn't covered by #2021. In what circumstance would an RP like to know the time since UV was performed, but not have the user perform UV if that time is longer than the RP is willing to accept?

[emlun]

The right-hand side should be a defined type, so uint in this case. But we can actually be even more prescriptive here and use the .within control operator to list all of the permissible values:

Suggested change

	timeSinceUv: timeSinceUvValue,
	timeSinceUv: uint .within (1024 / 2048 / 4096 / 8192 / 16384 / 32768 / 65536 / 131072 / 262144 / 524288 / 1048576 / 2097152 / 4194304 / 8388608 / 16777216 / 33554432 / 67108864),

(This is equivalent to just timeSinceUv: 1024 / 2048 / ... / 67108864, but I figure that adding uint .within helps clarify the CBOR type used to represent the number.)

It's... a bit ugly, but I think it's worth it. It would look slightly prettier if we decide to go with only even powers of two (i.e., powers of four) (but don't take that as a valid argument for changing to powers of four):

      timeSinceUv: uint .within (1024 / 4096 / 16384 / 65536 / 262144 / 1048576 / 4194304 / 16777216 / 67108864),

[timcappalli]

2024-04-19 WebAuthn F2F meeting: consensus to put this PR (and its alternative #2021) on hold until some details around attestation and conformance in FIDO are ironed out.