This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
Session lifetimes are usually short-lived in R&E federations and even shorter in other scenarios such as Open Banking. Therefore, the login status of these IdPs might be set to logged-out. Even if IdPs have a permanent "logged-in" status, requesting their account endpoints would likely not result in any logged-in accounts. In R&E, this should be seen as a common scenario. The FedCM modal dialog could allow the user to choose an organization instead of a specific account in such cases.
Organization Chooser
We propose to add an organization chooser dialog to the FedCM flow in such cases. This dialog would be similar to the "use another account" affordance in button mode. Except, it would also display organizations whose IdPs have registered in the browser but there are no logged-in accounts found.
The FedCM flow would not fail for a registered IdP if there are no logged-in accounts returned by the accounts endpoint. Instead, such IdPs would be given "candidate" status and client metadata would still be requested for them. In the subsequent dialog, a "Sign in using your OrgX account" button would be shown, including a logo and name queried from the IDP's registered config.json. If the user chooses such a candidate IdP, a login dialog according to the IdP's loginURL is opened. After the user authenticates and closes this dialog, accounts can be retrieved again.
To avoid a NASCAR problem in this dialog, the number of IdPs with "candidate status" would need to be rather small. This would require a way for the browser to filter IdPs in FedCM as proposed in here.
FedCM as an automated WAYF solution
In R&E federations, it is common for WAYF/IdP discovery services to be used by RPs to determine the user's home IdP. The WAYF service is commonly called by the RP, prompts the user for selection of an IdP, and returns the selected IdP to the RP. The RP then redirects the user to the IdP, where the user authenticates. Upon successful authentication, the IdP redirects the user back to the RP. A popular example of such a service in the R&E sector is SeamlessAccess.
We expect WAYF services to continue playing a role in the R&E sector, because of technical difficulties as described here. During the transition phase to "native" FedCM login, it would be great for FedCM to offer a browser-mediated WAYF-like functionality with good UX. FedCM is managing the login at the IdP itself and returns an opaque token to the RP. Instead of a token, FedCM would just return the URL of the selected IdP to the RP. The RP could then proceed with the regular federated authentication procedure, i.e., using SAML or OIDC.
An additional parameter might be used by RPs to trigger this WAYF mode, e.g., via a wayf option in the IdentityCredentialRequestOptionsContext. This mode would work with all other modes, even if only a single configURL is given by the RP. It would make most sense in the "any" mode, or if the RP supplied a (large) list of IdPs it supports. If set, FedCM would skip Step 7 (POST request to assertion endpoint). In Step 8, the URL of the IdP would be returned instead of a token.
This issue is part of the meta-issue, which documents all our FedCM 4 R&E related issues.
Session lifetimes are usually short-lived in R&E federations and even shorter in other scenarios such as Open Banking. Therefore, the login status of these IdPs might be set to logged-out. Even if IdPs have a permanent "logged-in" status, requesting their account endpoints would likely not result in any logged-in accounts. In R&E, this should be seen as a common scenario. The FedCM modal dialog could allow the user to choose an organization instead of a specific account in such cases.
Organization Chooser
We propose to add an organization chooser dialog to the FedCM flow in such cases. This dialog would be similar to the "use another account" affordance in button mode. Except, it would also display organizations whose IdPs have registered in the browser but there are no logged-in accounts found.
The FedCM flow would not fail for a registered IdP if there are no logged-in accounts returned by the accounts endpoint. Instead, such IdPs would be given "candidate" status and client metadata would still be requested for them. In the subsequent dialog, a "Sign in using your OrgX account" button would be shown, including a logo and name queried from the IDP's registered config.json. If the user chooses such a candidate IdP, a login dialog according to the IdP's loginURL is opened. After the user authenticates and closes this dialog, accounts can be retrieved again.
To avoid a NASCAR problem in this dialog, the number of IdPs with "candidate status" would need to be rather small. This would require a way for the browser to filter IdPs in FedCM as proposed in here.
FedCM as an automated WAYF solution
In R&E federations, it is common for WAYF/IdP discovery services to be used by RPs to determine the user's home IdP. The WAYF service is commonly called by the RP, prompts the user for selection of an IdP, and returns the selected IdP to the RP. The RP then redirects the user to the IdP, where the user authenticates. Upon successful authentication, the IdP redirects the user back to the RP. A popular example of such a service in the R&E sector is SeamlessAccess.
We expect WAYF services to continue playing a role in the R&E sector, because of technical difficulties as described here. During the transition phase to "native" FedCM login, it would be great for FedCM to offer a browser-mediated WAYF-like functionality with good UX. FedCM is managing the login at the IdP itself and returns an opaque token to the RP. Instead of a token, FedCM would just return the URL of the selected IdP to the RP. The RP could then proceed with the regular federated authentication procedure, i.e., using SAML or OIDC.
An additional parameter might be used by RPs to trigger this WAYF mode, e.g., via a
wayfoption in the IdentityCredentialRequestOptionsContext. This mode would work with all other modes, even if only a single configURL is given by the RP. It would make most sense in the "any" mode, or if the RP supplied a (large) list of IdPs it supports. If set, FedCM would skip Step 7 (POST request to assertion endpoint). In Step 8, the URL of the IdP would be returned instead of a token.