- From: Nina Satragno via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Mar 2023 15:53:56 +0000
- To: public-webauthn@w3.org
> 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 :thinking:. > 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. -- GitHub Notification of comment by nsatragno Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1854#issuecomment-1462302662 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 March 2023 15:53:58 UTC