Relax the number of providers in the .well-known file to 5-10

[samuelgoto]

We kept it at 1 to avoid a tracking attack, and we've always assumed that we would be able to extend it to a handful of URLs (but not arbitrarily).

We got feedback from Identity Providers that it would be constructive to relax it to 5-10 to allow them to represent different development servers, like qa, staging, canaries, etc.

[jameshartig]

In additional to development environments there are also different regions that might need to be listed like eu.idp.com or us.idp.com if an IdP has customers segmented to different regions.

[solatsuta]

Hello @samuelgoto.
I'm implementing the FedCM API, but after releasing it to production, I'm having trouble verifying it in the dev environment.
Here is my example.

• production: idp.example.com
• development: dev-idp.example.com

Do you have plans to move forward with this issue?

[samuelgoto]

I'm implementing the FedCM API, but after releasing it to production, I'm having trouble verifying it in the dev environment.

Can you point me to your production environment? What's a configURL that I could use?

[solatsuta]

I'm sorry.
Currently only RP has access to the Released production environment.
RPs are tested for operation before being released to the public for users.
Therefore, there is no configURL that can be opened to the public.

[cbiesinger]

If this is for testing purposes only, you can turn on chrome://flags/#fedcm-without-well-known-enforcement

[samuelgoto]

If this is for testing purposes only, you can turn on chrome://flags/#fedcm-without-well-known-enforcement

There are a couple more things that we are actively working on that may help here:

1. We are exploring bypassing the .well-known check if the RP and the IdP are inside the same eTLD+1. So, if you could have all your RPs under dev-rp.idp.example then we would skip the check if it was pointing to idp.example.
2. We are exploring offering an alternate .well-known check that allows multiple configURLs to exist if they all share the same accounts_endpoint. In this formulation, the .well-known file would announce an acccounts_endpoint as an attribute that, when available, would skip the check for the provider_urls.

@solatsuta any chance (1) or (2) or the chrome://flag that @cbiesinger mentioned above would help you with your problem?

[solatsuta]

@samuelgoto @cbiesinger
Thanks for letting me know.
My problem cannot be solved satisfactorily in either case.

(1): it is difficult to make the RP belong to the same eTLD+1 as the IdP.
The RP is a different company/organization than the IdP we manage. It would be practically impossible to put them under the same domain.

(2): IdPs are separated by subdomains. Therefore, it is not possible to have account_endpoints with the same URL.
If you only need to specify the path for the account_endpoint, this method solves my problem.

chrome://flag: It is obvious that this method solves this problem as a behavior. However, as mentioned in (1), there are so many RPs, which are completely different companies/organizations.
It would be difficult to lecture and verify the correct operation for all of them.

As an IdP, I provide multiple environments to RPs.
I have two examples, but there are many others such as sandbox, staging, beta, etc.
So the most desirable thing that comes to mind at this point is for provider_urls to be able to set up multiple environments.
This is the only way I can think of as they all belong to the same eTLD+1 and are separated by subdomains.

[npm1]

So to clarify, you have multiple IDPs under the same eTLD+1? Or just multiple environments of the same IDP?

[solatsuta]

@npm1

just multiple environments of the same IDP?

This is the correct understanding!

We have corrected the mistake.
#333 (comment)

[npm1]

Oh ok. So why do those environments have different account endpoints? I would imagine a user only has to sign in once to be able to access two of these environments?

[solatsuta]

Here is an example of how to get the accounts_endpoint from idp's config.json.

1. GET: example.com/.well-known/web-identity

{
  "provider_urls": ["https://idp.example.com/config.json"]
}

2. GET: idp.example.com/config.json

{
  "accounts_endpoint": "idp.example.com/accounts.php",
  "id_assertion_endpoint": "idp.example.com/assertion.php",
}

I have multiple environments that I want to get config in 2. Here is an example.

• idp.example.com
• dev-idp.example.com
• sandbox-idp.example.com
• stg-idp.example.com
• etc.

Since the DB that manages the user is different in each environment, this cannot be resolved with a single sign-in.
Here is an example of how DBs and domains are related.

• idp.example.com <-> prod-DB
• dev-idp.example.com <-> test-DB
• sandbox-idp.example.com <-> sandbox-DB
• stg-idp.example.com <-> prod-DB

As you can see, the DBs are separated by domain, so it is important for users to be aware of their domain when they sign in.

[solatsuta]

@npm1
OH sorry. There is a contradiction in my earlier answer.
My earlier answer is my mistake, sorry for the confusion. I will answer again.

So to clarify, you have multiple IDPs under the same eTLD+1?

This is the correct understanding.
Please assume the environment of the above answer for details.

[npm1]

Ok, thanks for clarifying! I don't have any good idea other than relaxing the number per the title of the issue. But that is going to be a tradeoff with privacy as it allows IDPs to add some entropy before the user has gone through the FedCM flow.

[cbiesinger]

It sounds like dev and sandbox could probably use chrome://flags, but yes, if there's multiple production IDPs that's problematic. We are hesitant to increase the number of providers due to privacy concerns, as npm says...

[solatsuta]

But that is going to be a tradeoff with privacy as it allows IDPs to add some entropy before the user has gone through the FedCM flow.

I feel you are right. I agree with the issue, if the IdP is malicious, they could track the same user information in multiple environments.

However, I think the fact that only one provider_urls can be registered may be a bottleneck for developers like me who release features after verifying them in multiple environments.
Currently, only idp.example.com can be registered, so if a problem is detected after a feature is released, it cannot be reproduced in the development or sandbox environment.

Of course, I understand that the above case can be avoided by using chrome://flags, but it is not realistic to tell RPs who use my IdP to set flags every time.

[samuelgoto]

I'd like to explore this option bit further.

We are exploring bypassing the .well-known check if the RP and the IdP are inside the same eTLD+1. So, if you could have all your RPs under dev-rp.idp.example then we would skip the check if it was pointing to idp.example.

You say:

(1): it is difficult to make the RP belong to the same eTLD+1 as the IdP.
The RP is a different company/organization than the IdP we manage. It would be practically impossible to put them under the > same domain.

And then:

idp.example.com <-> prod-DB
dev-idp.example.com <-> test-DB
sandbox-idp.example.com <-> sandbox-DB
stg-idp.example.com <-> prod-DB

These are all test environments, right? Are they publicly accessible? Why would they be exposed externally to external RPs? Are you saying that there are RPs, outside of the IdP's eTLD+1, that you'd like to be able to test against your test environments?

[solatsuta]

These are all test environments, right? Are they publicly accessible? Why would they be exposed externally to external RPs? Are you saying that there are RPs, outside of the IdP's eTLD+1, that you'd like to be able to test against your test environments?

No. idp.example.com is a production environment. It is open to the public.
sandbox-idp.example.com is not open to the public, but is open to RP.

We also provide a sandbox environment for RPs.
I provide a variety of functions to developers in addition to IdP, and developers need an environment to combine and develop those functions.

For example, chat API, image API, etc.
The developer wants to run those APIs from the development environment and make sure the set of built-in functionality works.
So I provide RP with a sandbox environment.

The sandbox environment is not open to the public, but allows RPs to achieve the same level of verification as production.

[samuelgoto]

sandbox-idp.example.com is not open to the public, but is open to RP.

What does it mean to not be "open to the public" but "open to RP"? Aren't external RPs "public"?

Do you mean "open to the public but there is an RP allowlist"?

[solatsuta]

The sandbox environment can only be accessed by a limited number of people through means such as IP restrictions or basic authentication.

The environment is open to the public on the Internet, but only developers registered on my platform can access it.

[samuelgoto]

The environment is open to the public on the Internet, but only developers registered on my platform can access it.

Got it. So, yeah, at this moment, I think the only solution that would work for you is asking all of your RPs to turn on this flag chrome://flags/#fedcm-without-well-known-enforcement in chrome while using your development environment.

Would that work? Or would that be too painful?

[solatsuta]

Would that work? Or would that be too painful?

Very painful in my personal opinion; I can easily foresee a large number of inquiries about FedCM not working.

A good number of RPs exist.
In order to continue to support FedCM in the future, we need to keep having RPs set chrome://flags at all times.

As an operation, we anticipate that it will be difficult to enforce this rule on all RPs.
I will continue to repeatedly announce the chrome://flags setting to support RPs. The cost of this would be very difficult for both RPs and me.

However, it is my understanding that this is the only realistic way to do this.
From now on, until provider_urls supports multiple config endpoints, we have no choice but to keep repeating the announcements.

[samuelgoto]

Another option that occurred to me was to having the IdP opt-inot "caching" the accounts endpoint value by using the IdP Sign-in Status API. That way, FedCM wouldn't have to hit the accounts_endpoint during the get() and also wouldn't have to check for the well-known file at all.

Caching the "accounts_endpoint" has some problems (e.g. fresheness), but I bet it would like do for, at least, testing purposes.

WDYT?

[npm1]

That probably does not work, even for testing. The devs could test the sandbox env but then the prod environment (or really any other) would be broken.

[samuelgoto]

That probably does not work, even for testing. The devs could test the sandbox env but then the prod environment (or really any other) would be broken.

The RPs would be pointing to either the dev/prod environment in the configURL, so both would work (e.g. dev would use the cached results and the prod environment would load dynamically).

[solatsuta]

Sorry, I'm not sure what to do.
I haven't figured out why the Sign-in Status API leads to a solution. This is my lack of study and I need time.

My understanding at this point is that doing so would mix up the login status for each environment.

[solatsuta]

Even if the Sign-in Status API were a solution to my issue, it would be difficult to adopt at this time.

For personal reasons, the default 3rd party cookie block that will take effect in 2024/1 will be very critical for my service.
Especially the worst case scenario is that the user's account information will be revoked.

To solve this problem, all RPs must bear FedCM compliant development.
Changing the IdP implementation now would put a huge burden on RPs and lead to loss of users.

We will consider this as a future alternative, but at least it will not be in time for 2024/1.

[npm1]

That probably does not work, even for testing. The devs could test the sandbox env but then the prod environment (or really any other) would be broken.

The RPs would be pointing to either the dev/prod environment in the configURL, so both would work (e.g. dev would use the cached results and the prod environment would load dynamically).

Not sure I follow, but I guess you mean caching the accounts (on a per-origin basis also?), not caching the accounts endpoint.

[samuelgoto]

Not sure I follow, but I guess you mean caching the accounts (on a per-origin basis also?), not caching the accounts endpoint.

Yes.

[cbiesinger]

? We have previously concluded that caching the account list is not workable.

[samuelgoto]

I'm now sure that was concluded. I certainly don't think it is true for every IdPs or for every test environments.

[cbiesinger]

IMO that will be a very complicated system to build purely for test environments

[cbiesinger]

See #552 for a proposal that helps for use cases that can reuse the accounts endpoint

[samuelgoto]

See #552 for a proposal that helps for use cases that can reuse the accounts endpoint

I feel that issue is now resolved with the latest proposal #552 , which would allow us to have an arbitrary number of configURLs. It does limit the accounts_endpoint to be only one per .well-known file, but we can try to relax that once we get there.

Closing, feel free to reopen if you fee like there is something else that we need to address.