Tracking through IDP with individualized account and client_metadata endpoints

[togamid]

What is preventing an IdP from inserting IDs as path parameters into the endpoints it specifies as a response to the config endpoint and using these IDs to match the accounts and client_metadata requests?
Suppose the response to the config request is as follows:

{
  "accounts_endpoint": "/random_id/accounts",
  "client_metadata_endpoint": "/random_id/metadata",
  "id_assertion_endpoint": "/assertion",
  "login_URL":"/login"
}

This leads to a credentialed request to "/random_id/accounts" and a request with the RP identifier to "/random_id/metadata" without any user interaction in Chromium as long as the IdP returns exactly one account.
An IdP can then use the "random_id" that is consistent between the two requests to combine them and track the user without permission.

I hope I'm wrong and have missed something obvious as FedCM relies heavily on separating these requests and I can't think of an obvious way to fix this.

[wparad]

Isn't that because the well-known endpoint response and the config.json have to match, and to counter that the random_id in the response must somehow end up being the same or else the browser will reject the config for that exact reason.

My understanding is that is the reason these two requests are made in parallel:

After that, I believe tracked urls no longer matter, because the user will only be tracked in contexts where the user could already be identified. But maybe I'm missing something.

[togamid]

It is not required to set an accounts_endpoint in the .well-known/web-identity file (see step 21 of this algorithm, there is no action if accounts_endpoint and login_url aren't set) .
The only thing that's required is the config endpoint, which isn't changed in this attack.

But you're right, forcing the account endpoint to be included in the .well-known/web-identity file would make tracking significantly harder (you could probably still give matching responses based on the IP-address or use an individualized config endpoint that gets added to the list of allowed config endpoints in the web-identity file on the fly)

[npm1]

Thanks for sharing, I think your attack is correct. We are thinking about mitigations