The interaction model between users, RPs, IDPs and the browser significantly changes in a FedCM style flow. Largely given sign-up, sign-in interactions and access authorization to resource servers are mediated by the browser - i.e., UX interactions that previously happened directly with the IDP - are now happening in some case without leaving the RPs site. This has been discussed already in multiple related tickets - #14 (comment), #264 (comment), #253 (comment)

This not only means that IDP interactions with users change, but also how RPs embed and address user to sign-in, sign-up or authorize other types of access requests. Today most sites are not built for this type of API but must be able to properly embed them into their user interactions model.

Simply triggering the API without any feedback (other than sometimes ending with a successful sign-in) and controls (other than it's only shown when a user is signed into an IDP) is not fit for purpose and could end up with suboptimal user-experiences especially also given how they operate in parallel to classical redirect flows (which will not go away any time soon).

This is even more relevant with:

• Multi-IDP support, where the RP must have some preference/priority w.r.t IDPs (to avoid winner takes it all scenarios)
• Support for use-cases to authorize general resource server access (where a RP sign-in is not needed/desired)
• Supporting IDP sign-in during API calls
• ...

The following flowchart illustrates the key controls / decisions from an RP side that come to mind initially interacting with a FedCM style API. Assuming the browser would not want to expose the user status, RP control could be established by allowing flags to be set while interacting with the API.