(Sorry in advance).
There are a number of white-label authentication providers today. Two prominent examples are Okta and Microsoft. A "white-label" provider provides an experience which is fully branded in the customer's branding, but hosted by the provider. Part of that "full branding" is hosting the authentication provider on the customer domain. That is, while Contoso could pay Okta or Microsoft to host authentication at contoso.microsoft.example or contoso.okta.example, they would more typically add a CNAME and host authentication at login.contoso.example or auth.contoso.example.
OAuth provides no protocol-level vendor lock-in here. If Contoso desires to switch from one provider to another, they can give one provider auth.contoso.example and the other provider login.contoso.example. Then, over a period of weeks to months, Contoso can update their applications from authentication with the old provider to the new provider. Finally, Contoso can terminate their contract with the old provider.
FedCM makes this sort of transition much more difficult, if contoso has a family of domains (contoso.example, contoso-products.example, contoso-acquired-subdivision.example). The well-known file hosted at https://contoso.example/.well-known/web-identity can either indicate the FedCM URLs are hosted on login.contoso.example or auth.contoso.example, but not both. Contoso cannot have a mix of products using vendor1 and vendor2's FedCM implementation in transition like Contoso could have a mix of products using vendor1 and vendor2's OAuth implementation in transition.
Fortunately, FedCM does solve this problem if Contoso has only a single domain (via skipWellKnown).
Something like Origin-only cookie retrieval could solve this problem. If login.contoso.example and auth.contoso.example could somehow declare that they only use cookies from their origins and that they should not see the top-level contoso.example cookies, we could lift the restriction that the well known file is retrieved from the apex domain (#809) and instead retrieve it from the origin, and thereby permit multiple FedCM providers within the same domain.
Edit: I have been convinced that origin-only cookie retrieval is too big a lift for the web platform to fit here.
(Sorry in advance).
There are a number of white-label authentication providers today. Two prominent examples are Okta and Microsoft. A "white-label" provider provides an experience which is fully branded in the customer's branding, but hosted by the provider. Part of that "full branding" is hosting the authentication provider on the customer domain. That is, while Contoso could pay Okta or Microsoft to host authentication at contoso.microsoft.example or contoso.okta.example, they would more typically add a CNAME and host authentication at login.contoso.example or auth.contoso.example.
OAuth provides no protocol-level vendor lock-in here. If Contoso desires to switch from one provider to another, they can give one provider auth.contoso.example and the other provider login.contoso.example. Then, over a period of weeks to months, Contoso can update their applications from authentication with the old provider to the new provider. Finally, Contoso can terminate their contract with the old provider.
FedCM makes this sort of transition much more difficult, if contoso has a family of domains (contoso.example, contoso-products.example, contoso-acquired-subdivision.example). The well-known file hosted at https://contoso.example/.well-known/web-identity can either indicate the FedCM URLs are hosted on login.contoso.example or auth.contoso.example, but not both. Contoso cannot have a mix of products using vendor1 and vendor2's FedCM implementation in transition like Contoso could have a mix of products using vendor1 and vendor2's OAuth implementation in transition.
Fortunately, FedCM does solve this problem if Contoso has only a single domain (via skipWellKnown).
Something like Origin-only cookie retrieval could solve this problem. If login.contoso.example and auth.contoso.example could somehow declare that they only use cookies from their origins and that they should not see the top-level contoso.example cookies, we could lift the restriction that the well known file is retrieved from the apex domain (#809) and instead retrieve it from the origin, and thereby permit multiple FedCM providers within the same domain.Edit: I have been convinced that origin-only cookie retrieval is too big a lift for the web platform to fit here.