Send Accept-Language in the HTTP requests

[samuelgoto]

From @ThisIsMissEm in #234 :

Also, when requesting Client Metadata, can the browser send the Accept-Language header to allow the IdP to return URIs to documents in The user's language?

I think this is a great idea: it doesn't seem immediately attackable to me and would certainly help the user.

[yi-gu]

hmm, since we don't (shouldn't) validate the URLs such that they are from the RP site, the URL could be decorated to be something like https://idp.example/rp/tos.html. When a user clicks on the browser UI to open this link, idp.example is able to connect the RP+User without explicit user permission since they have 1P cookie access from the decorated link.

Does it make sense?

[aaronpk]

Isn't that true with the current method the IdP provides the two URLs? That doesn't seem like it changes with the Accept-Language proposal here.

[samuelgoto]

hmm, since we don't (shouldn't) validate the URLs such that they are from the RP site, the URL could be decorated to be something like https://idp.example/rp/tos.html. When a user clicks on the browser UI to open this link, idp.example is able to connect the RP+User without explicit user permission since they have 1P cookie access from the decorated link.

I think we'd make sure that the url is passed within the same constraints that clientId is: either on unauthenticated requests or post user consent.

[yi-gu]

Isn't that true with the current method the IdP provides the two URLs? That doesn't seem like it changes with the Accept-Language proposal here.

Right. This doesn't seem to introduced by this proposal (it does get me started to think about this issue). Will track separately after we understand the situation better.

[ThisIsMissEm]

Yeah, a lot of big service providers have their different language terms at completely different URLs, not content negotiated based on Accept-Language, hence having the FedCM Client Metadata being able to language aware to support such a use case.

[TallTed]

ConNeg can be put to good use where a user does a GET doc.en with Accept-Language: ru. The server can respond with doc.en and headers (or links within doc.en) pointing to doc.ru, or doc.ru and headers (or links within doc.ru) pointing to doc.en, or a simple "pick one" page showing links to doc.en and doc.ru. Note that each of doc.en, doc.ru, etc., can have its own direct URI, and no two of these even need be served by the same authority.

I cannot think of a way that having a client-side tool be language aware solves the problem of a GET doc.en request where the user would prefer but is unaware of doc.ru, except leveraging ConNeg.

[ThisIsMissEm]

@TallTed my suggestion here is that when making the FedCM client metadata request, we ConNeg it, allowing the server to return potentially localised URLs for terms_of_service_uri and privacy_policy_uri

The FedCM client metadata request is a well known URL, due to specification requiring its implementation.

But it's not specified whether it is requested with headers that would enable ConNeg on Language

[TallTed]

But it's not specified whether it is requested with headers that would enable ConNeg on Language

Much clearer; thank you. Yes, FedCM requests should include Accept-Language and any other ConNeg request headers that are intended to guide the server to respond with the client's desired resource representation upon a single request.

[ThisIsMissEm]

i.e., we do:

GET /client_metadata?client_id=1234 HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Accept: application/json
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
Sec-Fetch-Dest: webidentity

(Assuming my device's languages would normally return fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5)

And idp.example may respond with:

{
  "terms_of_service_uri": "https://rp.example/fr/terms",
  "privacy_policy_uri": "https://rp.example/fr/privacy"
}

Instead of:

{
  "terms_of_service_uri": "https://rp.example/terms",
  "privacy_policy_uri": "https://rp.example/privacy"
}

(note: there's a typo in the original example 10 from https://fedidcg.github.io/FedCM/#idp-api-client-id-metadata-endpoint as /client_medata instead of /client_metadata)