Integrate with the Permissions API or its model?

[hober]

@Brandr0id wrote, in #29 (comment):

Now that we have a concept of a map storing the storage access flags does it make sense to just integrate with permissions that are keyed to the top-level and embedder origins rather than introduce a storage access map that's unique to this spec?

I could see the [=storage access map=] being a permission for Storage Access set with the [=partitioned storage key=] properties and the state "granted" or "denied" representing a success/failure of the API. The presence of the permissions "prompt" state and the concept of potentially prompting the user for access if no implicit grant is made may also tie nicely into this.

[hober]

See also #12.

[jimmywarting]

I would like to se the Permission API being used instead of document[hasStorageAccess|requestStorageAccess].
Annoying to have to see new permission proposal all the time with different quirks and api structure

the permission api have two things i was currently interested in, namely revoke and potentially observing for changes

[annevk]

Integrating with the model is tracked in #121.

If we integrate with the API, is the expectation that permissions.query() and hasStorageAccess() are aligned? It's not entirely clear to me that's possible given how storage access is scoped differently. In that Permissions are typically origin-scoped (though here they would be origin+top-level-site-scoped) and storage access is document/page-bound.