-
Notifications
You must be signed in to change notification settings - Fork 4
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
Reputation Tarnishing via presentation as an IDP #5
Comments
One solution would be to include a link tag, well-known resource, or uri in the request to allow a domain to show up for the redirect case. This would require a cross-origin request to the IDP before UI as shown up though. However if it is well-known we would mitigate the harms from link decoration. |
I find this overall a fundamental challenge of supporting the cold redirect case. To show an IDP origin in UI we should have IDP opt-in. To have IDP opt-in we need to send them a request (if we haven't been to the page before). To send them a request we need user opt-in. To have user opt-in we need to show the IDP origin. This is a cycle! I believe the weakest point of the cycle is "To send them a request we need user opt-in." Especially since the request is partitioned. This means that the solution space above would be the best way to break the cycle. |
In an offline conversation with Anne, he raised the following concern from requestStorageAccessFor: WebKit/standards-positions#125 (comment). Specifically, emphasis mine
This applies here. We should have an answer for it!
The text was updated successfully, but these errors were encountered: