@rhiaro @atanassov and I took a look at this today in our virtual f2f. We had some minor concerns but it appears that the CG is already aware of those and is working on solutions. We're happy to see this move forward.

Hey TAG,

I wanted to reopen this issue based on discussion during BlinkOn (and the suggestion by @slightlyoff), where we presented some ideas on how to solve multi IdP support. The key constraints about the solution space are:

• We want to allow IdPs to work independently. RPs should be able to just embed SDKs of different IdPs.
• This means it would be hard for IdPs to all be included in the same get() call. But if we wait for all get() calls, how do we ensure all IdPs are shown in the FedCM UI?
• RPs may also have a preference for an IdP even when they support more than one.

So we have some ideas on how to go about this:

1. Have an array of providers. This is a simple solution that is easy to understand, but requires IdP collaboration and RP changes. Also, the RP might need to determine which IdP the token received is from, and direct to the relevant IdP code to parse it. We think we can start with this solution as a baseline to enable multi IdP support, but might still need to supplement this to allow non-collaborative multi IdP support.
2. Wait until a certain point in time. For example, we explored gathering all get() calls received until onload, and showing UI which includes all IdPs that have invoked FedCM until that point in time. This has the advantage of not requiring IdP collaboration, but it is unpredictable, hard to understand, and causes performance concerns (the UI will show much later now even in the single IdP case).
3. Dynamically update the UI: show accounts as they are received. This has the disadvantage of producing shifts which may be annoying to users. In particular, if we want to surface returning accounts more prominently, we might need to reorder all accounts every time an IdP returns accounts. This option also makes it harder for the user agent to let RPs specify a preference on IdP ordering.
4. IdP registration: add a new method IdentityProvider.register() so that the IdP can tell the user agent that it wants to be part of the FedCM UI. There are two options here: have separate get() calls for each IdP (but then the waiting problem is just moved to the register method), or have a single get() call to show all registered IdPs (but then it puts the burden on the RP to determine when all IdPs have been registered).
5. Cache to estimate when to wait until. We will already know logged in IdPs via IdP login status API. We keep track of a global idps_used, a map from RP origin to a list of IdPs that we see the RP uses via FedCM. When we first see a get() call in the page, if idps_used is nonempty for the RP then we wait for those (with some cutoff like in solution 2), otherwise we wait (with the same cutoff) for all IdPs that are marked logged in according to IDP login status. Along with having some form of IdP registration / unregistration for RPs to update idps_used, we expect most cases to not hit the cutoff but instead meet the conditions and hence we eliminate performance concerns of solution 2.

In order to enable RP to state their preference of some IdPs, we also have some ideas:

1. Order in which IdPs are mentioned in array (applies to solution 1).
2. New JS method to state ordering.
3. Use the order in which RP embeds IdP SDKs.

Does TAG have an opinion on the solutions presented, or any other alternative?

I can't reopen issues here it seems, so appreciate it if someone can reopen on my behalf. Thanks!

Hi @npm1, really sorry it's taken us so long to get back around to this issue. Since several months have passed, could you update if you've made any progress on the questions you posed? Which route seems the most promising to you at this point?

Hi, are current plan is to first solve a subset of the problem: allowing multiple providers in a single get() call. Under the constrained version of the problem, we allow multiple IDPs but only if they are specified in a single get() call. We don't think this poses too many API questions as we already shaped the API to allow passing an array of providers, so I think we are good on that front.

Having said that, we have not made much progress on the other question, which is how to aggregate the providers from multiple get() calls. For our initial proposal of waiting until onload, we gathered metrics which showed that this would result in a fairly large regression, so we are probably not moving forward with that solution. Hence the brainstorm ideas from Oct 19 above still apply.

We discussed this in our call today. It seems like a good solution from a UX perspective would be if the IDPs are loaded dynamically, but without causing layout shifts in the content of the webpage (we all hate when a button we were about to click on is suddenly displaced from under our pointer). Have you thought about making this part of the browser chrome, rather than the site? Essentially moving the rendering responsibilities from the RP to the user agent.

User agents have historically had horrible UX with basic auth and certificate auth, it would be good for users if the UA could play a more active, and consitent, role in managing logged in state and UX for all forms of authentication. This implies creating other APIs beyond FedCM to handle other forms of authentication, but they could have a uniform UX. Do you think this is a direction you could see FedCM going in, in the future?

We discussed this in our call today. It seems like a good solution from a UX perspective would be if the IDPs are loaded dynamically, but without causing layout shifts in the content of the webpage (we all hate when a button we were about to click on is suddenly displaced from under our pointer). Have you thought about making this part of the browser chrome, rather than the site? Essentially moving the rendering responsibilities from the RP to the user agent.

That is how the API works today. The current API lets the user agent take control over the UI shown for a single get() call. In the future, it will be possible for the RP to only invoke get()s and get the user agent UI 'for free'.

User agents have historically had horrible UX with basic auth and certificate auth, it would be good for users if the UA could play a more active, and consitent, role in managing logged in state and UX for all forms of authentication. This implies creating other APIs beyond FedCM to handle other forms of authentication, but they could have a uniform UX. Do you think this is a direction you could see FedCM going in, in the future?

Yes, this is indeed the direction FedCM is going in. This also enables future work like reconciling different authentication choices (password/federation/passkeys) in a single user agent UI.

It looks like the explainer link is 404ing. Where'd it move to?

It moved to the issue fedidcg/FedCM#319 (comment). The explainer is a bit more detailed in that it talks about an onload heuristic (idea 2 above) but it turned out to be not performant enough (delays showing too much). I can write something up if that is too unclear.