Integrate with the Permissions API or its model?

[hober]

@Brandr0id wrote, in https://github.com/privacycg/storage-access/pull/29#issuecomment-620909194:

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.

[titi714]

În vin., 7 oct. 2022 la 13:34 Anne van Kesteren @.***> a scris:

Integrating with the model is tracked in #121 https://github.com/privacycg/storage-access/issues/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.

— Reply to this email directly, view it on GitHub https://github.com/privacycg/storage-access/issues/32#issuecomment-1271419780, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARSVDCZUHTBDCRNDD77KIO3WB74EFANCNFSM4MTILOAA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[johannhof]

See my comment in https://github.com/privacycg/storage-access/issues/121#issuecomment-1273185185

Maybe we should dupe #121 into this one or vice-versa @annevk?

[annevk]

I was hoping we could use this issue for the API discussion in particular, which I think is somewhat distinct. Although perhaps they need to be decided upon jointly.

[titi714]

Salut

În lun., 10 oct. 2022 la 17:43 Anne van Kesteren @.***> a scris:

I was hoping we could use this issue for the API discussion in particular, which I think is somewhat distinct. Although perhaps they need to be decided upon jointly.

— Reply to this email directly, view it on GitHub https://github.com/privacycg/storage-access/issues/32#issuecomment-1273424427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARSVDCZNIC64TO3IY3PBCRTWCQTQXANCNFSM4MTILOAA . You are receiving this because you commented.Message ID: @.***>