- From: Jeffrey Yasskin <notifications@github.com>
- Date: Thu, 01 Dec 2022 11:20:15 -0800
- To: w3c/permissions <permissions@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/permissions/pull/390/review/1200153098@github.com>
@jyasskin approved this pull request.
> + </ol>
+ </p>
+ <p>
+ A <dfn class="export">permission key</dfn> has its type defined by a feature's [=powerful feature/permission key type=].
+ <aside class="note">
+ The permission key defines the scope of a permission grant, which is usually per-origin.
+ Powerful features may override the [=powerful feature/permission key type=] to specify a custom permission key.
+ This is useful for features that want to change the granularity of permissions based on additional context,
+ such as double-keying on both an embedded origin and a top-level origin.
+ </aside>
+ </p>
+ <p>
+ To determine whether a [=permission key=] |key1| <dfn class="export" data-dfn-for="permission key">is equal to</dfn> a [=permission key=] |key2|, given a {{PermissionDescriptor}} |descriptor|, run the following steps:
+ <ol class="algorithm">
+ <li>
+ If |key1| is not of |descriptor|'s [=powerful feature/permission key type=] or |key2| is not of |descriptor|'s [=powerful feature/permission key type=], return false.
I'd still rather assert here, but I see that @annevk suggested returning false, and I don't think it's critical. It's still probably a bug if this ever gets called with different types.
> + A <dfn class="export">permission key</dfn> has its type defined by a feature's [=powerful feature/permission key type=].
+ <aside class="note">
+ The permission key defines the scope of a permission grant, which is usually per-origin.
+ Powerful features may override the [=powerful feature/permission key type=] to specify a custom permission key.
+ This is useful for features that want to change the granularity of permissions based on additional context,
+ such as double-keying on both an embedded origin and a top-level origin.
+ </aside>
+ </p>
+ <p>
+ To determine whether a [=permission key=] |key1| <dfn class="export" data-dfn-for="permission key">is equal to</dfn> a [=permission key=] |key2|, given a {{PermissionDescriptor}} |descriptor|, run the following steps:
+ <ol class="algorithm">
+ <li>
+ If |key1| is not of |descriptor|'s [=powerful feature/permission key type=] or |key2| is not of |descriptor|'s [=powerful feature/permission key type=], return false.
+ </li>
+ <li>
+ Return the result of running |descriptor|'s {{PermissionDescriptor/name}}'s [=powerful feature/permission key comparison algorithm=], passing |key1| and |key2|.
I think @annevk suggested:
```suggestion
Return the result of running the [=powerful feature/permission key comparison algorithm=] for the feature named|descriptor|'s {{PermissionDescriptor/name}}, passing |key1| and |key2|.
```
in #395.
> + </ol>
+ </p>
+
+ </p>
Something's wrong with the markup here. :)
> + <p>
+ To <dfn class="export">get a permission store entry</dfn> given a {{PermissionDescriptor}} |descriptor| and [=permission key=] |key|, run these steps:
+ <ol class="algorithm">
+ <li>
+ If the user agent's [=permission store=] [=list/contains=] an [=entry=] whose [=permission store entry/descriptor=] is |descriptor|, and whose [=permission store entry/key=] [=permission key/is equal to=] |key| given |descriptor|, return that entry.
+ </li>
+ <li>
+ Return null.
+ </li>
+ </ol>
+ </p>
+ <p>
+ To <dfn class="export">set a permission store entry</dfn> given a {{PermissionDescriptor}} |descriptor|, a [=permission key=] |key|, and a [=permission/state=] |state|, run these steps:
+ <ol class="algorithm">
+ <li>
+ Let |newEntry| be a new [=permission store entry=] whose [=permission store entry/descriptor=] is |descriptor|, and whose [=permission store entry/key=] [=permission key/is equal to=] |key| given |descriptor|, and whose [=permission store entry/state=] is |state|.
The comparison happens in the step after this one, and that step should still use the descriptor.
> @@ -278,6 +278,71 @@ <h3>
reset because its [=permission/lifetime=] has expired.
</p>
</section>
+ <section>
+ <h3>
+ Permission Store
+ </h3>
+ <p>
+ The user agent maintains a single <dfn class="export">permission store</dfn> which is a [=/list=] of [=permission store entries=].
+ </p>
+ <p>
+ The user agent MAY remove [=entries=] from the [=permission store=] when their respective [=permission=]'s [=permission/lifetime=] has expired.
+ </p>
+ <p>
+ A <dfn class="export" data-local-lt="entry">permission store entry</dfn> is a [=tuple=] of {{PermissionDescriptor}} <dfn class="export" data-dfn-for="permission store entry">descriptor</dfn>, [=permission key=] <dfn class="export" data-dfn-for="permission store entry">key</dfn>, and [=permission/state=] <dfn class="export" data-dfn-for="permission store entry">state</dfn>.
I was thinking of removing it entirely, but I don't hate most of the remaining uses of it. This use should probably be
```suggestion
A <dfn class="export" data-local-lt="entry">permission store entry</dfn> is a [=tuple=] of {{PermissionDescriptor}} <dfn class="export" data-dfn-for="permission store entry">descriptor</dfn>, an instance <dfn class="export" data-dfn-for="permission store entry">key</dfn> of the [=permission key type=] of the feature named by [=permission store entry/descriptor=].name, and [=permission/state=] <dfn class="export" data-dfn-for="permission store entry">state</dfn>.
```
I haven't double-checked that the exact names in that suggestion are right.
> @@ -278,6 +278,71 @@ <h3>
reset because its [=permission/lifetime=] has expired.
</p>
</section>
+ <section>
+ <h3>
+ Permission Store
+ </h3>
+ <p>
+ The user agent maintains a single <dfn class="export">permission store</dfn> which is a [=/list=] of [=permission store entries=].
I think it's important to mention the invariant here, but not super important which Infra data structure holds the entries. I'd initially thought of suggesting a [set](https://infra.spec.whatwg.org/#sets), but then I realized that sets are still ordered, and they only add uniqueness by item identity, but you need uniqueness by something else, so a list (with the explicit invariant) is probably better than a set.
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/390#pullrequestreview-1200153098
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/permissions/pull/390/review/1200153098@github.com>
Received on Thursday, 1 December 2022 19:20:28 UTC