Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send Accept-Language in the HTTP requests #592

Open
samuelgoto opened this issue May 21, 2024 · 9 comments
Open

Send Accept-Language in the HTTP requests #592

samuelgoto opened this issue May 21, 2024 · 9 comments
Labels

Comments

@samuelgoto
Copy link
Collaborator

samuelgoto commented May 21, 2024

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
Copy link
Collaborator

yi-gu commented May 21, 2024

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
Copy link

aaronpk commented May 21, 2024

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
Copy link
Collaborator Author

samuelgoto commented May 21, 2024

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
Copy link
Collaborator

yi-gu commented May 21, 2024

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
Copy link

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
Copy link
Contributor

TallTed commented Jun 4, 2024

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
Copy link

ThisIsMissEm commented Jun 4, 2024

@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
Copy link
Contributor

TallTed commented Jun 4, 2024

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
Copy link

ThisIsMissEm commented Jun 4, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants