The variable "loginStatus" is only set once in the Create Identity Credential algorithm, in step 7.3. It may also be set in 7.4, but does not have to. This means that it can have the values "logged-in", "logged-out" and "unknown" in step 7.11 , which deals with a failed request to the accounts endpoint.
This is problematic in 7.11.2, which says "If loginStatus is logged-in, set providerMap[providerOrigin] to "mismatch" and continue.". If I read this correctly, the algorithm only executes the "continue" and skips to the next iteration if the original loginStatus was "logged-in". If this is correct, the algorithm advances to 7.12 if the loginStatus was "logged-out" or "unknown", where the assert fails.
It would probably be better to split 7.11.2 into three steps. One sets the providerMap to mismatch if the loginStatus was "logged-in", one sets it to "logged-out" in the other cases and the third executes the "continue".
However, this creates a privacy issue. If the user agent does not set a loginStatus of "unknown" to "logged-out" in 7.4, the algorithm can reach 7.11.3 without ever showing UI. This might lead to a silent failure in step 13 despite IdP cookies having been sent, which circumvents the last part of the answer to question one in the Privacy Questionaire.
Such a change also has to be carefully reviewed for follow up consequences. One thing I already noticed is that it might allow the RP to determine whether the original login status was "unknown" by provoking a failure which skips the randomization in step 13.
Another thing I noticed is that the algorithm seems to handle the case of a providerMap that just contains "logged-out" weirdly, potentially displaying (or not displaying) empty UI in step 18 and eventually failing another assert in step 21.
The variable "loginStatus" is only set once in the Create Identity Credential algorithm, in step 7.3. It may also be set in 7.4, but does not have to. This means that it can have the values "logged-in", "logged-out" and "unknown" in step 7.11 , which deals with a failed request to the accounts endpoint.
This is problematic in 7.11.2, which says "If loginStatus is logged-in, set providerMap[providerOrigin] to "mismatch" and continue.". If I read this correctly, the algorithm only executes the "continue" and skips to the next iteration if the original loginStatus was "logged-in". If this is correct, the algorithm advances to 7.12 if the loginStatus was "logged-out" or "unknown", where the assert fails.
It would probably be better to split 7.11.2 into three steps. One sets the providerMap to mismatch if the loginStatus was "logged-in", one sets it to "logged-out" in the other cases and the third executes the "continue".
However, this creates a privacy issue. If the user agent does not set a loginStatus of "unknown" to "logged-out" in 7.4, the algorithm can reach 7.11.3 without ever showing UI. This might lead to a silent failure in step 13 despite IdP cookies having been sent, which circumvents the last part of the answer to question one in the Privacy Questionaire.
Such a change also has to be carefully reviewed for follow up consequences. One thing I already noticed is that it might allow the RP to determine whether the original login status was "unknown" by provoking a failure which skips the randomization in step 13.
Another thing I noticed is that the algorithm seems to handle the case of a providerMap that just contains "logged-out" weirdly, potentially displaying (or not displaying) empty UI in step 18 and eventually failing another assert in step 21.