Allow conditional and modal flows to run simultaneously about webauthn

[nsatragno]

What would be nice is if the RP only had one challenge outstanding, and it could be satisfied by either the autofill UI or a modal interface.

Would that be useful knowing the limitation that Conditional UI requests have stricter requirements (e.g. they only allow discoverable credentials, no timeouts, no errors reported)?

Right now the aborted conditional UI request can't be restarted so the RP has to wire up reinitialization of conditional UI in this scenario.

This is not a spec issue, and you can definitely do that on chrome (:

In both scenarios, "concurrent" and "pausing", it'd be possible to interact with conditional UI after modal UI though,

The RP could choose to ignore the result of the conditional UI promise. But this starts to sound like it's similar in complexity to having to abort the request 🤔.

unless perhaps success from one (i.e. the Promise resolving) keeps all other existing requests "paused"? thinking

I would be against this. RPs may have reasons to reject a result even if the promise resolves (e.g. because they didn't get some extension they needed, or because they want to reject the attestation). And then they would have to manually restart conditional UI, so we moved the problem to a more obscure edge case that still needs to be handled.

[nsatragno]

How about instead of supporting "concurrent" requests, we paused the conditional request while the modal request is happening? This would allow browsers to not worry about authenticator race conditions between both requests and would free RPs from having to handle the case. In practice, this probably means we abort-then-restart just like a website would, but opaquely. I think Apple's original implementation did something like this (haven't caught up to the current behaviour). A modal request from a child frame would also pause a parent frame's request.

We'd have to update credman as Emil points out above, but it can definitely be done.

[sbweeden]

What would be nice is if the RP only had one challenge outstanding, and it could be satisfied by either the autofill UI or a modal interface. Imagine the onClick action of a button on the same page as the autofill input field, being the thing that invoked the modal "version" of the interface. Ideally only one (the autofill) WebAuthn call need be made in JS, and the button just invoked the modal version of that while pausing the autofill version.

[FlxMgdnz]

From our experience with implementing conditional UI, we would very much welcome the proposed change.

[MasterKale]

How about instead of supporting "concurrent" requests, we paused the conditional request while the modal request is happening? This would allow browsers to not worry about authenticator race conditions between both requests and would free RPs from having to handle the case.

I like this idea, to me whether it's "concurrent" or not wouldn't be here-nor-there to the RP. Thinking through a bit, I think RP's are more concerned that one of the requests is in-progress.

And come to think of it, if a conditional UI request is "paused" during modal UI but becomes unpaused when the modal UI ends then it'd actually be an improvement. This would mean that conditional UI could be used if the user decides to cancel out of the modal experience. Right now the aborted conditional UI request can't be restarted so the RP has to wire up reinitialization of conditional UI in this scenario.

In both scenarios, "concurrent" and "pausing", it'd be possible to interact with conditional UI after modal UI though, unless perhaps success from one (i.e. the Promise resolving) keeps all other existing requests "paused"? 🤔

[nsatragno]

We went over this issue at the working group meeting yesterday (and I forgot to click submit on this comment).

I think it would be fine to allow a modal request during a Conditional UI request. The Conditional UI request would be paused until the modal request finishes (successfully or not). This would require changes in both credman and webauthn.

I believe Shane mentioned he wanted to take another look at my previous comment and come back to the thread.

[emlun]

See also: #1790. Seems like this is governed by the Credential Management spec, which WebAuthn hooks into. This is currently handled in step 6 of §2.5.1. Request a Credential, which currently matches only on [[type]] regardless of the corresponding mediation values.

[MasterKale]

Speaking a little to developer experience, needing to be mindful of aborting existing CredMan requests is an aspect of WebAuthn API that is unlike most other browser APIs. As such I think it'd be more ideal for developers to be able to "fire and forget" requests.

Implementing JS logic to juggle abort controllers when implementing both Conditional and Modal UI flows on a page is not too onerous a task, speaking from practical experience. However we're essentially consigning every RP to have to write such logic (or find a third-party library that does this) if we don't consider updating Credential Management API to achieve this.

Speaking for developers I'd say it'd be worth it for the easier WebAuthn learning curve. However I acknowledge that this would introduce a lot of complexity into the Credential Management API given its current architecture. The ball is with the browser vendors now and if they'd want to take on such an effort.

[sbweeden]

I am ok with allowing both concurrently from the client-side JS with the conditional UI request being paused whileever a modal is running. I'd like the test cases to include the ability to abort the conditional requests from the promise handler of the modal request if that sounds reasonable?

Also is there any reason why you couldn't use the same challenge (retrieved once from the server) for both these requests?

[timcappalli]

2023-08-30 meeting: @nsatragno @sbweeden did we still want to pursue this? I think there were some concerns about the experience across clients if some implemented this and others didn't as there is no feature detection for something like this.