Support for cascaded/staged federation scenarios

[achimschloss]

As mentioned in the last working group calls the current proposal does not support more complex federation scenarios well, i.e. scenarios where the IDP setup is more complex and does not rely on a single eTLD+1 in terms of user interactions.

We discussed such a use-case in a working group session and pushed it into the use-case library here - fedidcg/use-case-library#7 - Happy to jump on a call to elaborate and discuss.

[achimschloss]

Any thoughts on that? The current implementation is largely focussed on social login cases where globally scaled IDPs operate on a single eTLD+1 in all cases, which technically means you'd have to do a fair amount of re-engineering if you don't + furthermore (aside form technicalities) would this naturally favour economies of scale as the biggest IDP (in terms of logged in users) would be able to offer a FedCM based login in most cases - this general issue is also addressed here #14 (comment) - supporting more complex/cascaded setups would adress some of those concerns.

[npm1]

I'm having a hard time understanding the request here. Is there a real example showcasing the scenario? Otherwise it sounds like multi-IDP login, which we do have plans to support.

[achimschloss]

I'm having a hard time understanding the request here. Is there a real example showcasing the scenario?

Sure ;) - our system is built like that with around 35 million active users ;) - One of our RPs is for example https://www.bild.de/ from @rblanck - If you proceed to the login section (upper right "Anmelden"), you can choose netID as your login choice. As described in fedidcg/use-case-library#7 this will first get you to an account chooser that effectively allows the user to select an IDP (the actual IDP that does authentication/authorization) based on your email adress (for example xxx@web.de leads to web.de, xxx@gmx.net leads to GMX,.... - both are the largest European email providers).

RPs only need to do a single technical integration (and client registration) and are able to sign in users with multiple European IDPs. Technically the system leverages OpenID connect for both internal as well as external integrations (RP facing).

Otherwise it sounds like multi-IDP login, which we do have plans to support.

It is as a matter of fact, but I would really like to avoid to "unbundle" our IDPs (directly integrate them with FedCM as singular IDPs) to use FedCM, or at least be able to hide the complexity from our RPs somehow.

[npm1]

Thanks for providing the real world example! Super helpful. If the user needs to input their email into a form first, I think the way I would see integration with FedCM for now would be to use the email to detect the correct IDP and based on that do the regular FedCM flow with single IDP. Note that FedCM currently does not allow user to provide information in the UI.

[achimschloss]

If the user needs to input their email into a form first, I think the way I would see integration with FedCM for now would be to use the email to detect the correct IDP and based on that do the regular FedCM flow with single IDP

I guess specifying the account based on e-mail adress is nothing special to us ;) The relevant bit here is that today our RPs only need to interact directly with endpoints on a single eTLD+1 whereas Authentication/Authorization happens (for security/privacy reasons) via re-directs on different eTDL+1s... (operated by the actual IDP) I guess there are more scenarios where this is the case

A regular FedCM Flow would mean we'd need to expose the IDPs Endpoints with FedCM APIs directly to RPs (or the Browser to be correct), which is the larger re-work scenario that I was referring to as not really something we'd be looking to do.

Specifically the points raised here #14 (comment) would become more problematic for us, if the RP would not get more controls in a multi-IDP implementation / priorisation options or the alike.