search

fedidcg / LightweightFedCM

A Work Item of the Federated Identity Community Group.
9 stars 4 forks source link

Reputation Tarnishing via presentation as an IDP #5

Closed bvandersloot-mozilla closed 6 months ago

bvandersloot-mozilla commented 8 months ago

In an offline conversation with Anne, he raised the following concern from requestStorageAccessFor: https://github.com/WebKit/standards-positions/issues/125#issuecomment-1422944814. 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 commented 8 months ago

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 commented 8 months ago

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.