Add permissions patches

[blu25]

---

Preview | Diff

[domfarolino]

Is this ready for my review right now or is it still in draft shape?

[blu25]

Is this ready for my review right now or is it still in draft shape?

This is ready for your review, but is not ready to be taken out of draft. There are a couple TODOs still in the patches that I need your input on how to handle.

[domfarolino]

There are a couple TODOs still in the patches that I need your input on how to handle.

Can you be more specific with what you need help on?

[blu25]

There are a couple TODOs still in the patches that I need your input on how to handle.

Can you be more specific with what you need help on?

I'm not entirely sure how to get access to the fenced frame config. There are 2 places where algorithms will need access to a fenced frame config object to get the required permissions to load:

1. the shared document creation infra which, when it calls the create permissions policy algorithm, will have access to the navigation params.
2. Step 19 in the main fetch algorithm, which will call a new algorithm (specified in this PR) that has access to the request and response object.

The fenced frame config piece isn't fully spec'd out, and I want to make sure that what I'm trying to do is actually feasible/the fenced frame config object is going to be in a place where both algorithms can access them.

[domfarolino]

I'm not entirely sure how to get access to the fenced frame config.

Let me make sure I understand: these are cases where you are effectively "inside" the fenced frame and you need to access i.e., the "fenced frame properties" implementation-equivalent object in the spec, right? (Basically what we have in DocumentLoader in our implementation inside the FF renderer?) In that case, I think you can do what we do in https://wicg.github.io/fenced-frame/#ref-for-fenced-frame-config-instance%E2%91%A2, including with the XXX box below until I fix that :/

Does that help?

[domfarolino]

Please feel free to mark all previous discussions has "resolved" with the GitHub UI just so I'm sure which ones still need attention vs which ones are indeed addressed.

[domfarolino]

Let me make sure I understand: these are cases where you are effectively "inside" the fenced frame and you need to access i.e., the "fenced frame properties" implementation-equivalent object in the spec, right? (Basically what we have in DocumentLoader in our implementation inside the FF renderer?) In that case, I think you can do what we do in https://wicg.github.io/fenced-frame/#ref-for-fenced-frame-config-instance%E2%91%A2, including with the XXX box below until I fix that :/

OK this was fixed in #80. Now you can just use https://wicg.github.io/fenced-frame/#navigable-fenced-frame-config-instance as it is referenced elsewhere.

[domfarolino]

@gtanzer Can you take a look at specifically the changes to fenced frame config (+ instance): https://pr-preview.s3.amazonaws.com/WICG/fenced-frame/74/4686c12...7c8a3ba.html#fenced-frame-config-required-permissions-to-load.

[domfarolino]

I added some more fixes and editorial content. I think this is all ready to go % one single comment!

[domfarolino]

Do we need to also modify this algorithm to "fence" the container policy look-up? Right now https://w3c.github.io/webappsec-permissions-policy/#define-inherited-policy-in-container looks at the container policy (which may contain 'none', self', 'src, '*', or an origin) and runs the "matches" algorithm there. I think we'll need to ensure that 'self', 'src', and "an origin" are "fenced" and fail right? Or is there a reason we don't have to do this?

[domfarolino]

Filed #82 so we can just land this PR now.