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.

Sign up for GitHub

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

Jump to bottom

Section 4.3 should be improved to suggest utilization of OHTTP to prevent correlation #80

Closed
kdenhartog opened this issue Jul 17, 2023 · 5 comments
Closed

Section 4.3 should be improved to suggest utilization of OHTTP to prevent correlation #80

kdenhartog opened this issue Jul 17, 2023 · 5 comments
Assignees
@msporny
Labels
during-CR This issue needs to be resolved during the Candidate Recommendation phase. pr exists

Comments

@kdenhartog
Copy link
Member

While content networks can be useful there's an inherent trust on the third party CDN to behave and not provide access to the information. Now that OHTTP is more mature, resolution should be encouraged over an OHTTP channel to prevent linking the verifier of the list to an IP address. This prevents correlation of the IP address to the resolution of the credential improving privacy.

https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html
@msporny msporny added the during-CR This issue needs to be resolved during the Candidate Recommendation phase. label Sep 10, 2023
@Sakurann
Copy link
Contributor

I understand the preference for OHTTP, but more mature is not sufficient to normatively point to it yet, IMO - it is not an RFC yet. I might be comfortable with saying "OHTTP should be used once it becomes an RFC"

@kdenhartog
Copy link
Member Author

kdenhartog commented Sep 15, 2023 •
edited
Loading

Just a non-normative reference in a privacy considerations section is all I had in mind since I believe those sections are non-normative anyways. I agree that this definitely should not be a normative requirement. In fact, OHTTP is just one way to solve this problem of preventing correlation. Other options are to use a simple proxy service with a trusted intermediary. For example, instead of a wallet calling directly to the status list it calls to a wallets backend proxy service which fetches the content on behalf of the wallet. This aligns pretty well with the trust boundaries of the wallet service anyways so there's in theory nothing wrong with that approach.

If we did normatively require this that seems bad right now anyways. That effectively means everyone has to use privacy gateway since AFAIK they're the only company offering the intermediary service so far. I believe Apple offers it as well to only apple customers via private relay service too. Hopefully in the future all of the big CDNs and cloud providers will also use this to prevent IP correlation more regularly.

@kdenhartog kdenhartog mentioned this issue Oct 25, 2023
Merged
@msporny
Copy link
Member

msporny commented Dec 30, 2023

PR #107 has been raised to address this issue. This issue will be closed once PR #107 has been merged.

@msporny msporny self-assigned this Dec 30, 2023
@OR13
Copy link
Contributor

OR13 commented Jan 13, 2024

This issue should be closed, the PR was merged.

The current text contradicts the JWT BCP.

@msporny
Copy link
Member

msporny commented Jan 13, 2024

PR #107 has been merged, closing.

@msporny msporny closed this as completed Jan 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@msporny msporny

Labels
during-CR This issue needs to be resolved during the Candidate Recommendation phase. pr exists
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@msporny @OR13 @kdenhartog @Sakurann