This bundles a few features that we would like to launch at the same time. We are bundling them together because they can be used by IdPs to implement authorization flows such as letting a user grant access to a user’s calendar to an RP. See also https://github.com/w3c-fedid/FedCM/issues/477. Continuation API: https://github.com/fedidcg/FedCM/issues/555 This lets the IDP open a popup window to finish the sign-in flow after potentially collecting additional information. Parameters API: https://github.com/fedidcg/FedCM/issues/556 This lets RPs pass additional data to the ID assertion endpoint Fields API: https://github.com/fedidcg/FedCM/issues/559 This lets RPs bypass the data sharing prompt in favor of the IDP prompting Multiple configURLs: https://github.com/fedidcg/FedCM/issues/552 This lets IDPs use different config files in different contexts without weakening FedCM privacy properties, by allowing one accounts endpoint for the eTLD+1 (instead of one config file, which is more limiting than necessary) Account labels: https://github.com/fedidcg/FedCM/issues/553 Combined with the previous proposal, this allows filtering the account list per config file without providing additional entropy to the IDP.
This feature provides primitives that make FedCM very extensible for IDPs. With the ability to pass additional data through the fields API and continuing the sign-in flow in a popup window, FedCM becomes a lot more customizable for IDPs. Scalable well-known and account labels allow IDPs to better adapt to different contexts by customizing the accounts shown per context and allowing different branding and endpoints. For privacy reasons (only) the accounts endpoint and the IDP login URL have to remain constant.
Explainers: https://github.com/fedidcg/FedCM/issues/555 https://github.com/fedidcg/FedCM/issues/556 https://github.com/fedidcg/FedCM/issues/559 https://github.com/fedidcg/FedCM/issues/552 https://github.com/fedidcg/FedCM/issues/553