Why does the IdP provide links to the Privacy Policy and TOS of the RP and not the RP directly?

[togamid]

According to the current specs, the IdP is required to provide a link to at least the privacy policy of the RP via the client_metadata_endpoint .
However, this is information that the IdP does not necessarily have (why should the IdP care where the privacy policy of the RP is located) and which can change at any time without any control of the IdP. Thus, the IdP needs to either ask the RP about this URL for every request or ask less frequently and risk providing outdated information.

Wouldn't it be better to have the RP supply links to the privacy policy and the terms of service during the get() call? It is the authoritative source and knows when this information changes. Providing the information like this would also eliminate at least one HTTP request and the corresponding overhead.

Am I missing something? Thanks for the explanation!

[aaronpk]

Yeah, this is because it's based on the "traditional" model of OAuth/OpenID where clients are preregistered at IdPs (e.g. you had to go register as a developer on Google's developer console in order to build a "sign in with google" button), so the IdP does have this information for the RPs.

This came up for me when I built the prototype of the IndieAuth integration where RPs do not have a prior relationship with IdPs. Here's an issue that's tracking the request:

w3c-fedid/idp-registration#8

[togamid]

Thanks for the reply, that issue is really interesting! I'm currently looking into writing a plugin to integrate FedCM into the Shibboleth IdP, so I'm not a stranger to pre-shared data. But even if all RPs are preregistered, the information could be out of date. In the Shibboleth environment, one common way to transfer this registration data is via signed xml files, which aren't updated constantly. So if the URL changes, it might not be corrected for some time.

I also just don't really see a benefit of loading these URLs through the IdP that would explain the numerous downsides connected to it (increased overhead, involvement of more organizational units if the RP website is changed, ...).

[npm1]

Hmm yeah I can see there benefit to a feature where the RP provides the PP/TOS via the JS call. Because at least right now this is all we get from the client metadata endpoint, we could just skip it altogether. Note that we had been considering adding a feature to this endpoint to check whether the IdP accepts this RP to avoid showing UI if this is not a permitted RP, so if/when we do that, the endpoint would not be skipped.

[samuelgoto]

Beyond what was already said, I think it is worth noting that I think this was purely "sequencing strategy" rather than "privacy violation". By that I mean: having the PP/TOS provided by JS seems like an extension to FedCM that wouldn't require it to violate any of the privacy requirements, so seems plausible to me.

So, I think the question actually is: does anyone need this (for real production users)? Or is this a hypothetical?

[togamid]

Without the need to provide the two URLs through the IdP, standard SAML 2.0 SP/RP Metadata should contain enough information to implement FedCM and route the SAML response through the returned token (as without the metadata URLs, only a client identifier and the requested information is strictly needed).

If the RP metadata URLs have to be provided by the IdP, it is nontrivial to add them to the SAML Metadata files. According to the standard (https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, Page 12), while SPs/RPs can specify a URL for further information as part of the tag, only one such URL can be specified per language which poses obvious problems if both a URL to the privacy policy and to the terms of service are supposed to be provided.