Add initial patch for CSP:EE style iFrame Inheritance

[Brandr0id]

Adds an initial spec patch to try to describe a CSP:EE inspired approach to handle iFrame inheritance as discussed in #1 .

This adds language around adding the attribute connectionAllowlist to define a required policy, the UA's requirement to send a notification of a Sec-Required-Connection-Allowlist header, and the ack/opt-in mechanisms for the embedded document. Additional language has been added to describe inheritance/as-strict-as behaviour.

[Brandr0id]

@mikewest here's an initial stab at a patch for the behaviour discussed in #1 . Happy to break it up, change aspects or clarify as needed but hopefully it's a reasonable starting point for everyone to review and align on how this should work.

[Copilot]

Pull request overview

This PR updates the Connection Allowlists Bikeshed spec to introduce a CSP: Embedded Enforcement–inspired mechanism for iframe inheritance, allowing an embedder to require (and propagate) a minimum connection allowlist constraint to framed documents via a new iframe attribute and accompanying opt-in/ack headers.

Changes:

• Adds an “Embedded Enforcement” model for iframe navigations, including inheritance (“as strict as”) semantics and blocking behavior when the framed document does not opt in.
• Defines a new <iframe connectionAllowlist> attribute plus Sec-Required-Connection-Allowlist (request) and Allow-Connection-Allowlist-From (response) headers.
• Adds strictness comparison and HTML navigation integration steps to enforce the requirement and propagate it to descendants.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mikewest]

Thanks! I've left some feedback below, with the overarching request for you to take a look at the approach and details in https://www.w3.org/TR/csp-embedded-enforcement/ and to help me understand either how we'd modify that document or this PR to ensure they're aligned and that we're not defining two distinct enforcement paths for policies. :)

cc @noamr and @domfarolino

[noamr]

I'm not yet sure how this works with workers, and how we enforce that a document's own required CA needs to intersect with the CA attribute before being passed on for nesting.

A lot of my other comments were already in what @mikewest responded.

Another big open question is whether same-origin contexts with a different required CA are allowed to communicate with each other (e.g. by BroadcastChannel or sharing a SharedWorker/service worekr, or by direct scripting).

Answering this question might require that a "required CA" is part of an agent origin cluster key.

[mikewest]

Another big open question is whether same-origin contexts with a different required CA are allowed to communicate with each other (e.g. by BroadcastChannel or sharing a SharedWorker/service worekr, or by direct scripting).

Answering this question might require that a "required CA" is part of an agent origin cluster key.

Regardless of the answer, I don't think it's one we need to address in this PR. :)

[noamr]

Another big open question is whether same-origin contexts with a different required CA are allowed to communicate with each other (e.g. by BroadcastChannel or sharing a SharedWorker/service worekr, or by direct scripting).

Answering this question might require that a "required CA" is part of an agent origin cluster key.

Regardless of the answer, I don't think it's one we need to address in this PR. :)

Maybe it should be as an ISSUE?

[mikewest]

@noamr:

Maybe it should be as an ISSUE?

I think it's distinct enough that you can just add it as a security consideration with an issue we can address in a distinct PR. Or as an ISSUE in the threat model? That might be clearer.

[noamr]

@noamr:

Maybe it should be as an ISSUE?

I think it's distinct enough that you can just add it as a security consideration with an issue we can address in a distinct PR. Or as an ISSUE in the threat model? That might be clearer.

I meant just add it as an ISSUE somewhere in the spec so that it clear that this is incomplete and there are a few remaining open issues.

[Brandr0id]

@mikewest, @noamr thanks for the eyes on this. Latest version should be up and hopefully addresses the existing feedback and bulk of the CSP:EE/Fetch spec alignment issues but happy to iterate further!

[noamr]

@noamr:

Maybe it should be as an ISSUE?

I think it's distinct enough that you can just add it as a security consideration with an issue we can address in a distinct PR. Or as an ISSUE in the threat model? That might be clearer.

I meant just add it as an ISSUE somewhere in the spec so that it clear that this is incomplete and there are a few remaining open issues.

Actually I missed that the integration with "create a policy container from a fetch response" handles workers. So I think this is fine.

[mikewest]

I'm swamped at the moment, apologies. Quick feedback that doesn't dig into anything important; will try to take a deeper pass later in the week.

[noamr]

You don't need the lt here if it's the same text. Also not sure you need for=requirement
Maybe have something in the dfn name that ties it to CA though? it's a pretty generic name

[noamr]

I found a few nits and this needs to be rebased. Otherwise I think I'm pretty happy with it but would like another look from @mikewest / @domfarolino

[noamr]

Another nit :)
I did another pass on it and it overall looks good.
One thing I suggest having in addition is an explainer that focuses on the use case and the API. It can make it easier to read a very technical spec when there is a more human readable explainer next to it.

[noamr]

LGTM % previous nits

[mikewest]

If Noam's happy, I'm happy. :)

Noam, please feel free to land this once the nits are addressed.

[noamr]

If Noam's happy, I'm happy. :)

Noam, please feel free to land this once the nits are addressed.

Thanks, nits + fix merge conflicts :)

[Brandr0id]

Thanks, @noamr should be updated and rebased now. I'll put up a parallel PR with an explainer to cover this also.