Manifest fingerprinting wording describes mitigation imprecisely

[will-bartlett]

The spec describes a fingerprinting attack in 7.3.1. It says:

Our mitigation to this problem is to use the § 3.1 The Well-Known File file. The existence of a file at the root of the IDP’s domain is enforced to ensure that the file name does not introduce fingerprints about the RP being visited.

The whole manifest could be in this location, but instead it only points to the real manifest from there. This allows the flexibility in the future to allow a small constant number of manifests, should an IDP require this in the future, instead of just a single one.

This commentary makes sense to me. However, the "Fetch the config file" algorithm does not actually do this. This algorithm allows a config to be valid in the "Check accounts and login url step" if the accounts and login url match those urls that appear in the well known file. The tracking domain can trivially return an unbound number of manifest files that have the same accounts and login urls.

[will-bartlett]

Part of the reason I open this issue is that Microsoft Entra's implementation (which is a sort of "IdP factory") would naturally lead to millions of manifest files, one per company, hosted at e.g. https://login.microsoftonline.com/{tenant}/fedcm-manifest.json. This is the normal pattern in Entra - to host one IdP under each https://login.microsoftonline.com/{tenant}/ prefix. If that's not going to work (i.e. if there is some limit), I'd like to know. But if it is going to work, I don't think manifest fingerprinting is really prevented.

[will-bartlett]

@npm1 corrected me on #775 . Manifest fingerprinting is only a concern for credentialed requests. Then this is not a substantive issue with the spec, just a wording issue.

Instead of:

Here, the RP includes identifies itself when fetching the manifest from the IDP. This coupled with the credentialed fetches that the FedCM API performs would enable the IDP to easily track the website that the user is visiting, without requiring any permission from the user. Our mitigation to this problem is to use the § 3.1 The Well-Known File file. The existence of a file at the root of the IDP’s domain is enforced to ensure that the file name does not introduce fingerprints about the RP being visited.

The whole manifest could be in this location, but instead it only points to the real manifest from there. This allows the flexibility in the future to allow a small constant number of manifests, should an IDP require this in the future, instead of just a single one. It also helps the IDP’s implementation because they any changes to the manifest are more likely to be performed on a file located anywhere, as opposed to the root of the domain, which may have more constraints in terms of ease of update.

The spec should say something like:

Here, the RP includes identifies itself when fetching the manifest from the IDP. This coupled with the credentialed fetches that the FedCM API performs would enable the IDP to easily track the website that the user is visiting, without requiring any permission from the user. Our mitigation to this problem is to use the § 3.1 The Well-Known File file. The existence of a file at the root of the IDP’s domain is enforced to ensure that the requests to credentialed endpoint do not introduce fingerprints about the RP being visited.

The whole manifest could be in this location, but instead it only points to the real manifest from there. This allows the flexibility in the future to allow a small constant number of credentialed endpoints called silently, should an IDP require this in the future, instead of just a single set. It also helps the IDP’s implementation because they any changes to the manifest are more likely to be performed on a file located anywhere, as opposed to the root of the domain, which may have more constraints in terms of ease of update.

Note: as this threat is focused on silent requests to credentialed endpoints, the mitigation is not applied to the Disconnect endpoint, which is not called silently.

Then, IIUC, it should be ok for Entra to host a manifest per tenant, as long as those manifests refer to a common accounts endpoint and id assertion endpoint.

[npm1]

Oh yeah thanks, we introduced the multiple config URLs thing later (initially, we enforced only one so the text was accurate) and we forgot to update that text. So let's keep this issue open to ensure that happens.