We've had a lot of discussions in other places, e.g. at TPAC in the past weeks that focused on how we can improve interop, the API design and security properties of the Storage Access API, in light of recent publications such as rSAFor and new security considerations for SAA.

One central idea that stuck with some of us is to reconsider some of the design choices that were made for rSA over time, particularly to revisit per-page storage access and move back to per-frame (I think @martinthomson brought this up first). There are various reasons why I think this is a good idea:

• As noted in Improving the Storage Access API security model #113, security considerations from per-page storage access would likely motivate us to enact restrictions on rSA that would reduce its utility for the per-page use case anyway, unless some opt-in signal from the first and/or third party is given. Most of these restrictions would no longer be necessary with per-frame
• Per-page storage access vastly extends on the API target use case of "authenticated embeds", and most of us would like to focus on this use case for rSA.
• Furthermore, the rSA API is actually quite inconvenient for providing per-page storage access as a compatibility measure. Sites that would not previously use iframes for their 3P resources would have to build weird constructs that "trick" users into clicking an iframe to open up storage access for e.g. images.
• The new per-frame design for rSA I'm imagining would ensure that adjacent same-origin iframes would retain the ability to get promptless storage access after an initial user grant. This may be even more convenient for developers than working around the restrictions suggested in Improving the Storage Access API security model #113.
• With rSAFor, we have a successor proposal for a page-wide "compatibility mode" API that we could work on and evolve with that specific intent and design goal, giving both APIs and use cases a cleaner separation.
• As a neat side effect, we would resolve almost all of the remaining interop challenges through aligning the spec and browsers with roughly what is shipping in Safari.

A few, probably incomplete, thoughts on how this would work:

• Browsers store a (top-level site, embedded origin) keyed permission (Consider building on top of Permissions instead of using the "storage access map" #121) that designates whether a user (agent) made the choice to allow or disallow storage access for that combination. Note that this does not grant implicit storage access as Firefox and Chromium would do right now, but instead signals that calls to rSA with that key would be auto-granted (see below).
• Any iframe document that wants to gain storage access needs to call requestStorageAccess. This would be auto-granted when the permission is present, i.e. the user had made the previous choice to allow (how long that permission is stored is implementation-defined). The storage access grant is designated through a flag on the browsing context and thus applies to future same-site navigations inside the same iframe. I believe that this is very close to what Safari does today.
• This means that when one iframe requests storage access, adjacent iframes will not get access automatically, but will be able to call rSA to get promptless access. As a result of this change I think we should be motivated to investigate further into Means to observe availability of storage access #55 and I believe that integration with the Permissions API should give us that possibility through observing the permission.
• Most other ideas such as maintaining storage access through continued user interaction as planned in Age Out Of Granted Storage Access #5 or potential future bucket-based localstorage access (Offer access to non-partitioned storage somehow #102) would still be compatible with this plan.

cc @annevk @bvandersloot-mozilla @mreichhoff @cfredric @johnwilander