Skip to content

Latest commit

 

History

History
25 lines (14 loc) · 1.52 KB

alternatives_considered.md

File metadata and controls

25 lines (14 loc) · 1.52 KB
Raw

Alternatives Considered

Now that we have a deep understanding of (a) the problem and (b) the motivations and topology of the parties involved, lets look at some why nots.

The Status Quo

A trivial alternative that is worth noting as a baseline is to "do nothing" and keep federation using low-level primitives like redirects and popups.

That seemed clear to reject based on:

  • the inability to prevent the RP tracking problem
  • the increasing constraints that are being put in place for cross-site communication through third-party cookies, postMessage and URL parameters as link decorations as a result of the IDP tracking problem

From here, the next incremental step we could look at is the requestStorageAccess API.

The RequestStorageAccess API

The Document.requestStorageAccess() API grants first-party storage to cross-origin subframes. In conjunction with iframes, an IDP could expose its service via cross-site postMessage communication once first-party storage has been granted.

That seemed clear to reject based on:

  • the inability to prevent the RP tracking problem
  • the general-purpose nature of the API leading to the lowest common denominator policy

From here, let's try to break down the problem into smaller parts.