FedCM multiple IDP support

This page contains a video recording of the presentation made during the session from Breakouts Day 2024, along with a transcript. Video captions and transcript were automatically generated and may not properly translate the speaker's speech. Please use GitHub to suggest corrections.

Video
Transcript

Video

Transcript

this breakout is about

Nicolas Pena Moreno: multi IDP support for FedCM, so I will start by giving a brief overview about
… what FedCM is, and then I will
… go ahead and present the problem and leave some time for a brainstorming session or any comments or suggestions people may have. So. as everyone is probably aware, third party cookies are being phased out. They already phased out in some major browsers like safari
… and firefox. but they're also being phased out in chrome as well. So this is how the
… chrome timeline looks like the idea is to face them out by
… the third quarter of this year. So that is pretty soon.
… However, there's a lot of things that rely on third party cookies.
… It's not just about tracking. So one example is federated login. If so. this is just one example website that currently uses
… an IDP (identity provider) iframe embedded within an RP (relying party), which is basically the website in this case, New York Times and
… with third party cookies. The IDP can have the accounts and their cookies inside of that a frame, but obviously. once
… those are no longer available. Then creating something like this is no longer possible. So
… in order to enable federation, like the one in the previous example, we created the FedCM API
… The UI is similar to what we currently see in some of these websites where we present some accounts to allow the user to pick an account
… from one of the IDP accounts to login to the
… RP. In this case, pinterest.
… Now one issue, one big issue with the current FedCM API is that it only allows a single identity provider. So in particular, if an RP wanted to show accounts from Amazon, Apple, Facebook, Google, Github Linkedin Twitter and Microsoft.
… then they would not be able to do so, even if those, even if all of those IDPS supported
… the FedCM API. So
… this is the problem we are
… trying to solve in this breakout.
… in particular, the end goal would look something like the this. Now I will note that this is just an example. Right? So
… first of all, the mockup is incorrect because it should say booking com instead of trained com. Sorry about that copy paste. Also, in this example, you can see 2 IDPs Google and Facebook. But obviously this is a web platform API. So
… the
… relying party may use whichever IDPs they choose to use in
… For for the purpose of federation. So they there's
… basically the RP is the one who decides which are the IDPs that are shown in the FedCM UI, but basically the goal is to have a ui, such. That
… accounts from the various IDPs that the user is already signed into are shown and they can pick one account from among those in order to sign into the website.
… Now, the current API looks like this. So we are hooking into the credential manager
… we call navigator credentials.get().
… and we pass an array of providers. We currently only allow an array of size, one. So a single provider, and then we pass some information about the provider. There's a config URL for the provider. There's a client id and announce but the key takeaway is that this is basically inside navigator dot credentials dot get, I will point out that
… at least in chrome, we are currently
… working on allowing a single navigator dot credentials, dot get
… to specify multiple identity providers. So in particular, in the providers array, you will be allowed to specify IDP one, and then id, p. 2, and so forth. So that does allow to solve part of the problem, but not
… the full problem, as I will explain in a bit.
… so what? What is the problem we're trying to solve?
… Well. we want certain conditions to
… be met in order for us to consider the problem solved right? So one important aspect about Federation is that
… while in some cases the IDPs may be owned by the same entity, or somehow be related or collaborating with each other.
… And the general case, like the example we saw with Google and Facebook, the IDPs may not be related to each other, so we should assume that they will work independently.
… In particular, it would be great if our piece are just able to embed, as as the case for each of the different ids. but still
… result in a unified FedCM UI, where we can show multiple account from all of those IDPs.
… So that's the second point, that because we have
… the assumption that IDPs may be independent, it is
… hard, or, let's say, almost impossible, for those IDPs to work together to be included in the same get call. So if they could
… all managed to be in the same. Get call, then we wouldn't need this session, because
… we we can. Relatively, it's relatively simple to add to have ui, when all of the ids are specified in the in the one single get call right? Is the
… really, not that many questions in that scenario. Basically, that's the easy.
… That's the easy scenario. But if there's multiple get calls or like IDPs, need to somehow add themselves in
… from different
… locations from different script locations, let's say, or like from their own SDKs. Then the question is, how do we allow that, but also show the ui in a prompt and like reasonable way.
… and finally, our piece sometimes have a preference for some id piece over other ids. So this is something that it would be nice to respect, which is, basically
… I love the RP to tell us what order the accounts should be shown in, which, again, is easy. If there's a single get call. but may be more complicated
… if we assume the IDPs are independent. So let's go over some brainstorm solutions to potentially solve this problem.
… and
… of course, the pros and cons of each solution.
… Some some of the solutions may be combined with each other, so they're not like, necessarily mutually exclusive. But there's just some ideas that we have been thinking about. So the first solution is to show an array of providers
… so sorry to allow an array of providers in a single get call. So that's what I've already been mentioning that we are planning to start allowing in chrome.
… so that is the
… how the Javascript would look like just basically multiple providers in the same get call.
… Now. this has some advantages, right? So no heuristics are required because the RP. Is now in charge of
… making this happen. They just tell us what they want from a single location. So that's very easy for us to parse, and we just grab all the id piece and
… try to fetch the accounts from those IDPs and then show them in the ui. It is also simple to understand
… and it also allows RP. Ordering to be specified by just showing in the ordering which they are provided in the in the array.
… But of course it has a very big con, which is that it assumes that
… the IDP.
… I sorry that the IDPs collaborate with each other, or that somehow the RP. Can manage to
… get all IDPs in the same get call
… which is not necessarily
… Oh. a reasonable assumption in today's world. Given that
… in today's world many RPs just embed separate IDPs case.
… Now, again, this is like obviously a big cons. But in some cases this is sufficient. Right like, for example, if all IDPs are owned by the same entity than this would be sufficient for that case. But perhaps it is not sufficient for other cases. So we are exploring other ideas.
… The second solution that we have explored is to wait until a certain point in time. So essentially.
… we allow multiple get calls
… to be included in the same browser. Ui.
… But in that case we need to figure out, when do we stop waiting for get calls right because
… we get us the first get call. Then we know, okay, we might get more get calls later. Right? So then we kind of need to set a cut off time where we are like, okay, no more get calls. Now, these are all the IDPs that will be included.
… and
… this is one example of how that could look like essentially
… the IP. One first invokes FedCM, then id, p. 2. Then, let's say, unload a curse.
… we consider that to be the cut off point and assuming that the get calls, the first get call happens before unload, and then
… that would be the solution. So the advantage of this solution is that
… IDPs can be independent. So we don't need IDP collaboration. Our piece can still embed as the case of their different IDPs, and they can just like opt in for the IDP to use FedCM
… or something like that. So they don't really need to get involved in coding. But the problem is, well, there's there's a couple of problems with this idea.
… One is that it is somewhat unpredictable. hard to understand. because the cutoff is kind of an arbitrary point in time so unpredictable in the sense that
… if the id piece are not careful, then in some cases they may, they may be included in the ui. In some cases they may not be included. Right? So it's like a a timing issue where some.
… because if they are too late, then they might not get to be shown in the the Ui, which is what the RP wants.
… and the other big issue which we have actually
… gathered some data on is that this introduces performance issues. So if we imagine the
… case that we currently ship in chrome right now, which is the single IDP case. For example, we still need to wait until the point in time where, when we are like, oh, this is the cut off for IDPs. So in the example, unload which means that
… even for the single IDP case there will be a delay in showing the FedCM UI. And we logged some data on this and noticed that
… for the specific
… point in time that we have, we are showing in the diagram which is the load event, the regression in terms of how late the FedCM UI shown would be very large.
… so that is a big issue with this second solution.
… Now in terms of how we would allow they are P to specify ordering in that solution.
… one option is to have a new Javascript method for
… set ordering
… where the RP. Would have to call it. Another option is to
… just let it be the order of the get calls
… or the ordering which the RP embeds the IDPs case, and not another option is to just
… let it be performance based. So basically, whichever IDP returns, accounts first will be shown. First, of course, this means that our piece would no longer get have any control over the Ui.
… Now, the third idea that we have is to have dynamically updated. Ui.
… So let's say, we are in shrine.com. And
… we initiate FedCM from 2 IDPs in this example. Facebook. And Google. Now let's say the first Id returns accounts. So we start showing ui, so it will be the ui you see, on the left.
… So it has the accounts corresponding to the first id, and then we show
… sorry. And then the another IDP response, with some other accounts.
… Then we update the ui by appending the accounts corresponding to that IDP.
… and we can keep doing that, I guess, for as long as IDPs keep
… returning accounts right
… now. This has some advantages like
… there is no IDP or RP. Collaboration required right? Because the get calls can be done independently. It is relatively easy to understand, because it's just
… adding new accounts. Every time a new get call occurs. and
… in some way it encourages IDPs to
… optimize for performance, because fast IDPs will be shown before slow IDPs which the IDPs cover, but because it would likely result in higher
… click through rates for that id.
… the one that is fast. This solution does have some issues, though. So
… either we allow account reordering, or we do not right.
… If we allow accounts to be reordered as new information comes in. Then that means that there's Ui shifts for the user, right? Because some account will. Now
… you shown at the top if we receive new information
… so that's really bad. However, if we do not allow account reordering, so we append accounts at the end of the current dialogue scroll bar right? Because the if there are like too many accounts, we, we can have a scroll bar
… the problem with that is that
… well, a couple of problems. One problem is that
… it means our piece can no longer specify the ordering, which is
… sort of a desirable property. And the other problem is that
… it might mean that an account that, as would that was previously used in FedCM may now show towards the bottom. Right? So if if imagine a user use FedCM
… on this website in the past with IDP 2 at IDP one returns first, then we show
… accounts from IDP one first
… and then later. We show accounts from, but we put them at the bottom. So the account that was used in the past will no longer be prominent prominent enough to the user, because we are not allowing the reordering of accounts.
… Now, another
… sort of solution is to have IDP registration. So basically, the IDPs can
… register themselves, which is essentially telling the user agent that
… they will at some point invoke, fets them
… and then later, they can evoke FedCM whenever they need to. But this does have some issues. Let's go with the benefits. First, first doesn't require IDPs to collaborate.
… and second. it allows our piece to express. Some preference by. Just.
… let's say, specifying it via the ordering which register is called, or something like that issues is well, first issue, it's backwards incompatible with the existing Api
… and second issue, it kind of delays the waiting problem to the register method. Right? So we have the same problem as we had with the get calls. But now
… it has just moved
… to the register method instead. Because now we need to decide. Until which point in time do we
… wait for all IDPs to have had a chance to register themselves. So that's the next. And lastly, before I give the

Sam Goto: if I let everyone speak their mind.

Nicolas Pena Moreno: The last idea we've had is to have some sort of IDP registration, but with a unified get call which will just be invoked after the IDPs have had a chance to register themselves. So
… there will be multiple register calls. There will be just one single get call which, just to tells the user agent to fetch accounts from all Ips that have registered themselves. So this solution allows again our piece to express their preferences for
… which IDPs they want to be shown first and whatnot?
… it has couple of issues. Well, one issue is that it could be backwards incompatible with the existing Api, although not necessarily right, because, if, like in this case, we're using a different different way of requesting the providers, right? So there could be
… the way where providers are specified in an array, or they could be the registered, previously dry registered provider, so depending on how it is specified. It could or could not be

Sam Goto: backwards. Incompatible.

Nicolas Pena Moreno: well, the single get call still requires
… RP, 2
… basically get involved. So obviously, this does not have the property that the RP. Can just keep just embedding independent IDPs case and
… have everything magically work for them right? Because then the RP. Would be probably the one that has to call the get after they have registered all the IDPs they care about.
… So yeah, those are all the ads. That we had. And
… yeah, the purpose of this session is to hear any ideas we have missed, or any questions or comments from people. So yeah, thanks for listening. And

Sam Goto: I don't know if these people want to speak. Just raise your hand or just unmute