Can we more formally define the "Permission Store"

[annevk]

And acknowledge that permissions are origin-bound. The specification is tiptoeing around this a bit and I (still) think it would be better if it didn't.

@jyasskin you thought differently from me I recall, but enough time has passed that we can maybe discuss it again.

Having permissions explicitly stored and them having a key would also help us define Storage Access in terms of Permissions: privacycg/storage-access#121.

[jyasskin]

I'll defer to the Chrome Permissions team, led by @engedy. I think I was concerned about giving UAs enough space to innovate in the permissions space, which a rigorous definition in terms of "store X; delete Y" might cause problems for. But if our permissions folks aren't worried, neither am I.

[annevk]

Thanks! I hope that the ample wiggle room we have now before you reach the store suffices. And it would help to have the boundary firmly established somewhere, both for implementers (I was reading the text again yesterday with someone and it is rather opaque as to what you actually have to do) and for features such as Storage Access.

[johannhof]

Yup, to be clear, for Storage Access we are in fact considering a different storage key than plain origin (origin + top-level site), so some freedom in the form of a "key" concept would be good. I agree with Anne though that the current vagueness makes it a bit harder to be sure that dependant specs are well understood by implementors.

[marcoscaceres]

Discussed with @miketaylr and yeah, we should add this. Right now permissions are not bound to anything so it would good to tie them to an origin-bound to some global "permissions store".

@annevk, what (conceptual) functionality should the permission store provide? Do you need "CRUD" permissions from the other spec?

[annevk]

I'm not familiar with "CRUD". What the Storage Access API needs is the ability to use a key that is different from origin (it wants (top-level site, origin). So I think ideally the various ways of setting and obtaining a permission take an optional key Storage Access API can decide upon.

Alternatively, we hardcode "storage-access" as a double-keyed permission. That might have the advantage that the WebDriver API would be simpler to use, although I'm not super familiar so we'd have to go through that to be sure.

[miketaylr]

(CRUD = create, read, update, delete)