Reputation Tarnishing via presentation as an IDP

[bvandersloot-mozilla]

In an offline conversation with Anne, he raised the following concern from requestStorageAccessFor: WebKit/standards-positions#125 (comment). Specifically, emphasis mine

Assume a top-level A that may or may not fetch a CORS script from B after a successful requestStorageAccessForOrigin() call. A and B are cross-site. In this case A can prompt on behalf of B without B having been involved, potentially tarnishing B's reputation.

This applies here. We should have an answer for it!

[bvandersloot-mozilla]

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.

[bvandersloot-mozilla]

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.