npm1
commented
5 months ago Yes, current implementation waits for all IDPs, which is indeed an issue especially for IDP registration. (b) is my current thinking even for the case when there are multiple get calls. Although we've heard that RPs would like to have a say as well and this is somewhat conflicting (unless we have some combination of (a) and (b) instead of relying entirely on order of arrival).
I'm trying the Multi IdP API in conjunction with w3c-fedid/idp-registration#2, and I realize that one single slow IdP can hang the entire account chooser dialog.
I have registered a particularly slow IdP, which can hang now all of my FedCM calls. That was an accident, but you could also imagine a (registered or not) IdP which attacks the others by being deliberately slow.
We should try to find a way to either (a) have a cut off / timeout or (b) gradually insert accounts into the account chooser as they get received.
I'm wondering if (a) forces us ultimately to also have to do (b), unless we entirely drop the responses after a certain timeout, meaning that we might as well go straight to (b) anyway.
Also, if we do (b), I bet that this can also solve the case where the browser can handle multiple
navigator.credentials.get()calls concurrently (by augmenting the account chooser as the accounts resolve).