How long the relying party should maintain the challenge and related information? about webauthn

[sbweeden]

IMO the RP provided timeout is how long to keep the challenge valid. The client knows this time and client side javascript can be used to obtain a new challenge as the timeout approaches. For autofill ui, you should be able to cancel a pending call, then start a new one. This was broken on Safari last time I tried but worked on Chrome (on Mac anyway).

[timcappalli]

@Kieun we should definitely add some clarity around the timeout and challenge, but I think the text around canceling a pending request is more deployment guidance, and not spec text. We can add this to passkeys.dev eventually.

[timcappalli]

We could potentially align the challenge validity with the RP requested timeout value, but since that is only a hint to the client, it may not be perfect. But at a minimum, it would at least provide a max window.

[Kieun]

If the browser aligns the RP requested timeout value, then anyway RP could invalidate expired challenge without worrying so much.
But in other aspects, after the request is timed out from RP and browser, then how the RP triggers Auto-Fill UI again?

[Kieun]

@sbweeden If it is the case, then the RP client should handle such timeout to cancel the pending request and this needs to be explained in somewhere in the spec.

[sbweeden]

I think this example, already in the spec, covers how to abort an in-progress request: https://w3c.github.io/webauthn/#sctn-sample-aborting

[Kieun]

@sbweeden I know the abort example was already there and we've been implementing it on our demo, but it would be good to indicate or explain to recommend aborting pending operation for auto-fill UI.

[MasterKale]

I think in general we could suggest RP's allow challenges to be used once within N minutes, because a user may walk away mid-ceremony and come back, and should be able to immediately re-attempt without needing to request new options. This has been our practical experience working with WebAuthn, mind you, and I suspect other RP's have done something similar without introducing any security issues into the auth flow.

[dolda2000]

I too recently grappled with this situation and eventually decided to use one global challenge per web session, unbounded by time, that is "consumed" when one (of potentially several) conditional sessions actually complete. I consider this a very imperfect solution, but I found it to be the least bad of the options I considered.

Unless it's too late, I would suggest changing/amending conditional mediation to a two-stage process, where a call is made back into the website script when a user actually decides to interact with the conditional mediation session, at which time a challenge can be fetched from the server. Just my two cents.