This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
FedCM provides a clear approach for RPs that support one or a few IdPs for user authentication. However, this approach does not yet scale well for multilateral federations, i.e., in the academic context, in which thousands of IdPs might be used for authentication. Similar issues are prevalent in Open Banking, where it is common to support many, bilaterally federated IdPs.
In such scenarios, it is important to have a method to filter out IdPs unsuitable for federated authentication at an RP. For example, an RP might only accept IdPs within the eduGAIN inter-federation. In this case, other IdPs (e.g. Google, Facebook) should not be shown in the dialog because it would result in failed authentication and poor UX if the user selected them.
In the following, we present two options that allow FedCM to filter IdPs based on affiliation/federation information provided by both RPs and IdPs. In both cases, we expect the resulting set of IdPs to be rather small for nearly all R&E users.
IdP-list approach
FedCM already allows RPs to supply a list of compatible IdPs to the browser in the navigator.credentials.get() call. Such a list can be fetched, parsed, and supplied to the browser as presented by @samuelgoto here. Still, this list needs to be filtered somehow.
Login Status
Currently, FedCM would filter this list by comparing it with IdPs with the login status "logged-in". This way, any IdPs that the user is not logged into are filtered out. However, session lifetimes are usually short-lived in R&E federations and even shorter in other scenarios such as Open Banking. Therefore, IdPs would be required to leave their login status as "logged in", even if the user's session has ended.
IdP Registration
Another approach would be to filter the list of IdPs based on their registration status in the browser. If an IdP has previously registered in the browser and is also in the list of compatible IdPs sent by the RP, we can be fairly certain that it can be used for federated authentication. Therefore it should be considered by FedCM, regardless of its login status.
This approach boils down to the "some"-mode that was discussed during OSW24 unconference sessions. Because this mode differs from the any-mode and gives a list of URLs, it would need to be signalled to the browser. This could e.g. be achieved through a "some" option in the IdentityCredentialRequestOptionsContext.
Feasibility
In R&E, RPs usually have a list of usable IdPs, e.g., from their metadata discovery service. That list is commonly is extensive (5.000+ IdPs in eduGAIN). We are unsure about the feasibility of such an extensive list being fetched and transmitted. However, we assume that this list would be hosted and managed by a central federation entity, allowing it to be cached by RPs.
affiliationHint approach
FedCM specifies loginHints and domainHints which are part of the data structure returned by the accounts endpoint. We propose an additional attribute called "affiliationHint". This attribute would be part of the IdP registration data, as it applies to the whole IdP. Similary, RPs would signal their affiliation hints in the navigator.credentials.get() call. The browser could then compare IdPs registered with the same affiliationHint and only display exact matches. This suggestions is similar to the idea presented by @samuelgoto here.
Example scenario
The Munich University of Applied Sciences (HM), is part of the German National R&E Network (DFN-AAI) and part of the inter-federation eduGAIN.
The University La Sapienza is part of the Italian national R&E Federation (GARR) and also part of eduGAIN.
The user has credentials from HM and Google, and accesses an RP operated by La Sapienza.
HM's IdP registered itself in the browser with affiliationHint = ["hm.edu", "dfn.de", "edugain.org"].
Upon user access, the Italian RP sends affiliationHint = ["uniroma1.it", "garr.it", "edugain.org"] within the navigator.credentials.get() call.
Affiliation hints are sorted hierarchically, i.e., the left-most entity is the lowest one.
The User Agent filters IdPs registered based on their affiliationHint.
The filtering process works as follows:
The UA compares the left-most affiliationHint of the IdP with all affiliationHints of the RP.
In case a match is found, the IdP is given candidate status.
Otherwise, the search continues.
In this example, only the last comparison is successful, as both the IdP and the RP are part of eduGAIN.
The browser continues with the regular FedCM flow and only HM accounts are shown to the user in the dialog
Functional Considerations
We further suggest to use entityIds as the affiliationHints because they exist in both SAML and OpenID Federation based multilateral federations. An RP sets its affiliationHints to a list of all entityIds of its superiors, i.e., all intermediates and roots of trust. In case the RP is part of multiple federations, it includes all relevant entityIds. In other scenarios where IdPs are not structured in such a hierarchical way, for example in Open Banking, other affiliation hints could be considered, e.g., "EU-bank", "US-bank", "credit-card-issuer", "savings-bank", etc.
RPs operated by federation member institutions can set their affiliationHints as they desire, for example:
An RP could call navigator.credentials.get() with affiliationHint = ["uniroma1.it"] to only suggest login to users from that university.
By setting affiliationHint = ["uniroma1.it", "garr.it"], login would also be suggested to other users within the Italian federation.
Similarily, IdPs can restrict their affiliationHints as they desire.
If an entity is part of more federations, the list could simply be extended with the additional affiliationHints.
Approach using OpenID Federation trust chains
Instead of affiliationHints, the RP could call FedCM including one or more OpenID Federation trust chains, as proposed in our paper. The entityIds in each entity statement could be parsed and used in the same way as in the affiliationHint approach. The RP's trust chain could subsequently be used to further filter the list of IdPs to only show trusted and compatible ones to the user.
Problem with multiple IdPs and no logged-in accounts
Finally, it is unclear how FedCM would proceed if there are multiple IdPs left after filtering with no logged in accounts. Even though we expect the resulting set of IdPs to be small for most users, it should be clear how FedCM proceeds in such a case. According to the current FedCM draft, the flow would either abort or show multiple IdP login dialogs. Both options seem suboptimal from a UX perspective. This issue is discussed in more detail here.
This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
FedCM provides a clear approach for RPs that support one or a few IdPs for user authentication. However, this approach does not yet scale well for multilateral federations, i.e., in the academic context, in which thousands of IdPs might be used for authentication. Similar issues are prevalent in Open Banking, where it is common to support many, bilaterally federated IdPs.
In such scenarios, it is important to have a method to filter out IdPs unsuitable for federated authentication at an RP. For example, an RP might only accept IdPs within the eduGAIN inter-federation. In this case, other IdPs (e.g. Google, Facebook) should not be shown in the dialog because it would result in failed authentication and poor UX if the user selected them.
In the following, we present two options that allow FedCM to filter IdPs based on affiliation/federation information provided by both RPs and IdPs. In both cases, we expect the resulting set of IdPs to be rather small for nearly all R&E users.
IdP-list approach
FedCM already allows RPs to supply a list of compatible IdPs to the browser in the navigator.credentials.get() call. Such a list can be fetched, parsed, and supplied to the browser as presented by @samuelgoto here. Still, this list needs to be filtered somehow.
Login Status
Currently, FedCM would filter this list by comparing it with IdPs with the login status "logged-in". This way, any IdPs that the user is not logged into are filtered out. However, session lifetimes are usually short-lived in R&E federations and even shorter in other scenarios such as Open Banking. Therefore, IdPs would be required to leave their login status as "logged in", even if the user's session has ended.
IdP Registration
Another approach would be to filter the list of IdPs based on their registration status in the browser. If an IdP has previously registered in the browser and is also in the list of compatible IdPs sent by the RP, we can be fairly certain that it can be used for federated authentication. Therefore it should be considered by FedCM, regardless of its login status.
This approach boils down to the "some"-mode that was discussed during OSW24 unconference sessions. Because this mode differs from the any-mode and gives a list of URLs, it would need to be signalled to the browser. This could e.g. be achieved through a "some" option in the IdentityCredentialRequestOptionsContext.
Feasibility
In R&E, RPs usually have a list of usable IdPs, e.g., from their metadata discovery service. That list is commonly is extensive (5.000+ IdPs in eduGAIN). We are unsure about the feasibility of such an extensive list being fetched and transmitted. However, we assume that this list would be hosted and managed by a central federation entity, allowing it to be cached by RPs.
affiliationHint approach
FedCM specifies loginHints and domainHints which are part of the data structure returned by the accounts endpoint. We propose an additional attribute called "affiliationHint". This attribute would be part of the IdP registration data, as it applies to the whole IdP. Similary, RPs would signal their affiliation hints in the navigator.credentials.get() call. The browser could then compare IdPs registered with the same affiliationHint and only display exact matches. This suggestions is similar to the idea presented by @samuelgoto here.
Example scenario
affiliationHint = ["hm.edu", "dfn.de", "edugain.org"].affiliationHint = ["uniroma1.it", "garr.it", "edugain.org"]within the navigator.credentials.get() call.Functional Considerations
We further suggest to use entityIds as the affiliationHints because they exist in both SAML and OpenID Federation based multilateral federations. An RP sets its affiliationHints to a list of all entityIds of its superiors, i.e., all intermediates and roots of trust. In case the RP is part of multiple federations, it includes all relevant entityIds. In other scenarios where IdPs are not structured in such a hierarchical way, for example in Open Banking, other affiliation hints could be considered, e.g., "EU-bank", "US-bank", "credit-card-issuer", "savings-bank", etc.
RPs operated by federation member institutions can set their affiliationHints as they desire, for example:
navigator.credentials.get()withaffiliationHint = ["uniroma1.it"]to only suggest login to users from that university.affiliationHint = ["uniroma1.it", "garr.it"], login would also be suggested to other users within the Italian federation. Similarily, IdPs can restrict their affiliationHints as they desire.If an entity is part of more federations, the list could simply be extended with the additional affiliationHints.
Approach using OpenID Federation trust chains
Instead of affiliationHints, the RP could call FedCM including one or more OpenID Federation trust chains, as proposed in our paper. The entityIds in each entity statement could be parsed and used in the same way as in the affiliationHint approach. The RP's trust chain could subsequently be used to further filter the list of IdPs to only show trusted and compatible ones to the user.
Problem with multiple IdPs and no logged-in accounts
Finally, it is unclear how FedCM would proceed if there are multiple IdPs left after filtering with no logged in accounts. Even though we expect the resulting set of IdPs to be small for most users, it should be clear how FedCM proceeds in such a case. According to the current FedCM draft, the flow would either abort or show multiple IdP login dialogs. Both options seem suboptimal from a UX perspective. This issue is discussed in more detail here.