Recommend duration of challenge validity

[emlun]

Fixes #1848.

Additions I also considered but decided against:

• Mentioning that the RP MAY enforce a shorter timeout if a shorter options.timeout is requested. I think the recommendation of a "similar" timeout probably communicates that this is a vague limit with a lot of wiggle room for such things.
• Recommending that challenges SHOULD NOT be valid past the recommended duration. This is softly implied, and doesn't seem necessary as this section comes from the angle of how long the RP needs to store the challenge, so the RP probably prefers a short time already.
• Recommending allowing only a single verification attempt per challenge/ceremony. While probably a good idea, it shouldn't matter much in practice, and there might be reasons to allow retrying in some cases. It's also perhaps not entirely clear what "once per ceremony" means - once per navigator.credentials.{create,get}() call or once per session? - so it might be more confusing than helpful.

---

Preview | Diff

[MasterKale]

I thought to suggest we frame "discouraged" vs "preferred"/"required" as "second-factor" vs "passwordless"/"passkeys", but maybe that framing is too "practical" to be included in the spec?

Anyway I think this looks good so I'm going ahead and approving.

[emlun]

Yes, I think that's a bit too much indirection. The reader has to do more work to relate those terms to the UserVerificationRequirement values, when we can just refer to them directly instead. Especially since this new section is also referenced in the client algorithms, I already think that "the [=[RP]=]'s [=user verification=] preference for the ceremony" is almost too informal as it doesn't explicitly and unambiguously say what defines that preference. But I think it's probably clear enough with the reference to the UserVerificationRequirement values.

[emlun]

2023-03-22 WG call: conditional mediation makes this a bit complicated. We might change the API a bit to better support conditional mediation, holding off on this one until that's decided.

[akshayku]

See also #1885 where I am proposing adjusting these ranges.

[emlun]

Updated to account for the changes in #1885.

[emlun]

@akshayku @sbweeden This is now updated to account for the changes in #1885, and ready for re-review.

[Kieun]

I was thinking that this issue is blocked until #1856 is resolved.
Regarding original questions for conditional-mediation, the RP client needs to abort request and only allow modal request if the user click some buttons?

[emlun]

Oh right, I forgot. This should probably stay blocked then. This issue is on the agenda for today's WG meeting, we'll decide on that then.

[ve7jtb]

LGTM