if clientId is issued by IdP, then IdP can know which RP attempted to connect

[jasonjiicloud]

I read the documentation: https://developer.chrome.com/docs/privacy-sandbox/fedcm-developer-guide/#idp-config-file.

It says the browser fetches the config file without the Origin and Referer header. This prevents the IdP from learning who made the request and which RP is attempting to connect.

But if clientId in navigator.credentials.get is issued by IdP to specific RP, then IdP can know which RP made the request.

So clientId will leak user privacy, so why do we use it?

I think my understanding is wrong. but where's the wrong?

[npm1]

I think you're assuming all the info in get() is passed to the config file fetch, which is not the case. The clientId is used in the client metadata fetch (where IdP should know the RP who is making the request), but not in the config fetch.

[jasonjiicloud]

@npm1, what's the difference? not only the client metadata, but also the assertion request, both of them use clientId, so certainly the IdP knows who tried to login, which RP attempted to connect.

@npm1 , please correct me.

[npm1]

The client metadata fetch will include the RP but not the user, so the IdP will not know who tried to login at that time. In the ID assertion fetch we do include both the user and the RP: the user has at this point accepted to use some IdP account for federated login in the RP, so it is acceptable for the IdP to know this at that time. Let me know if it makes sense and I can close this issue?

[jasonjiicloud]

I'm clear. but what's the significance of not letting the IdP know the Referer and Origin when fetching config file, the IdP will know when doing ID assertion?

[yi-gu]

For the ID assertion fetch, it happens after user grants permission via the "Continue as" button on the FedCM UI. So it's OK (and necessary) for the IdP to known user A is visiting RP B such that they can issue a token.

For any other fetches, the browser should only include either RP info (client id, Origin etc.) or user credential but not both to make sure that the IdP does NOT learn about a specific user's visit to a specific RP (they can learn user A is visiting SOME RP or SOME user is visiting RP B).

For the config fetch in particular, suppose it's https://idp.example/fedcm.json. If the browser includes the RP info (e.g. Origin) in the request, then the IdP can return the endpoints like this:

{
  "accounts_endpoint": "https://idp.example/rp-origin/accounts",
  "client_metadata_endpoint": "https://idp.example/clientmetadata",
  "id_assertion_endpoint": "https://idp.example/id-assertion"
}

Later when the browser sends user credentials to the accounts_endpoint (without sending RP information of course), the IdP can learn about the RP as well via the path in the endpoint.

Does it make sense?

[jasonjiicloud]

@yi-gu , I understood most of your point of view.

The IdP can learn a specific user's visit to a specific RP only when user grants permission. I got it.

But for the config fetch, I don't agree:

You said the IdP could return a malicious URL "https://idp.example/rp-origin/accounts", then the IdP could get the RP information from this URL. But according to the rule, the account assertion does contain "Origin" header, so the IdP doesn't need that malicious URL.

If I have something wrong, please correct me.

Thank you.

[yi-gu]

Actually the browser does NOT include RP info (Origin, client id etc.) in the account endpoint request. The only two endpoints we include RP info are the client metadata endpoint and ID assertion endpint.

[jasonjiicloud]

@yi-gu, you're right. I understood it. Really appreciate it. Sorry for taking your time.