Re: [w3ctag/design-reviews] FedCM multi IDP support (Issue #803)

Hey TAG,

I wanted to reopen this issue based on discussion during BlinkOn (and the suggestion by @slightlyoff), where we [presented](https://docs.google.com/presentation/d/1vAq0rK40tqgb4XIku0CKPqKIn9fd9ZGUTEstu4WQkBE/edit#slide=id.g24dab4effb5_0_0) 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.
1. 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).
1. 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.
1. 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).
1. Cache to estimate when to wait until. We will already know logged in IdPs via [IdP login status API](https://github.com/w3ctag/design-reviews/issues/884). 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).
1. New JS method to state ordering.
1. Use the order in which RP embeds IdP SDKs.

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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/803#issuecomment-1771557647
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/803/1771557647@github.com>