Guten TAG!

I'm requesting a TAG review of a "credentialless" cross-origin embedder policy mode.

Today, COEP: require-corp exists, and is used to enable cross-origin isolation (and therefore SharedArrayBuffer, etc). It is functional and solid, but turns out to be difficult to deploy at scale, as it requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc). https://github.com/mikewest/credentiallessness/ suggests an alternative that might have better deployment characteristics: strip credentials from outgoing requests by default, and send them only for CORS-enabled requests. In this model, resources would either explicitly opt-into sharing themselves with the requestor, or would be low-risk, insofar as it's less likely to contain personal information if browser-controlled identifiers like cookies aren't included.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/credentiallessness
• Security and Privacy self-review²: Let me get back to this when we're further along... It should be strictly positive.
• Primary contacts (and their relationship to the specification):
  • Mike West (@mikewest), Camille Lamy (@camillelamy), Ian Clelland (@clelland)
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Nope.

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG, or just WHATWG PRs, as it might not be complicated enough for an entirely separate doc.
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG (this would live in HTML (and maybe bits in Fetch?))
• Existing major pieces of multi-stakeholder review or discussion of this design: This is it. Being my favourite standards review body, y'all are first on my list.
• Major unresolved issues with or opposition to this design: None (yet!).
• This work is being funded by: Google

You should also know that: the subresource bits of this proposal seem pretty clear to me, and I have some reasonable amount of confidence that they make sense. Frames are harder, and I'd appreciate y'all's thoughts. I'd also appreciate your help weighing the impact of non-cookie based ACLs, and the potential dependency upon CORS-RFC1918 (which y'all are reviewing in https://github.com/w3ctag/design-reviews/issues/572. It might also be helpful to review conversations like https://github.com/whatwg/html/issues/4175#issuecomment-466047231 where @clelland originally surfaced this suggestion.

We'd prefer the TAG provide feedback as:

💬 a comment in this issue and @-notify the folks above.