Cross-Origin-Embedder-Policy: credentialless

[ArthurSonzogni]

Specify the behavior of Cross-Origin-Embedder-Policy: cors-or-credentialless,
Originally described in: https://github.com/mikewest/credentiallessness

cors-or-credentialless and require-corp are similar. One or the other is a requirements for the window.crossOriginIsolated capability. They both share the same set of checks.
They differ mostly in the fetch specification. require-corp requires a CORP header for cross-origin no-cors responses. cors-or-credentialless doesn't, but omits credentials (Cookies, clients certificates, etc...) in exchange.

I am opening this bug to reference several PR against the HTML, Fetch and ServiceWorker spec. So they can be discussed more widely.

Some tentative tests have been written into the wpt repository:
https://wpt.fyi/results/html/cross-origin-embedder-policy/credentialless/cors-or-credentialless?label=master&label=experimental&aligned&q=cors-or-credentialless

[annevk]

Why would cors be part of the name?

Also, I still stand by w3ctag/design-reviews#582 (comment).

[annevk]

Also had a question about how this works for navigations. It seems to me that if the parent document has cors-or-credentialless, the child can have either that or require-corp. But if the parent has require-corp, the child shouldn't be allowed to have cors-or-credentialless perhaps as that's weaker? (Especially once most things cross-origin are without credentials anyway.)

[ArthurSonzogni]

Thanks @annevk!

Why would cors be part of the name?

Either the request is sent via CORS with credentials, and you must get explicit opt-in from the cross-origin server. Or it is sent in no-cors mode without credentials => cors-or-credentialless.
What do you think?

---

Also, I still stand by w3ctag/design-reviews#582 (comment).

The main issues we had was:

• Defining a solution for <iframe>. @camillelamy is preparing an explainer about this to share. Maybe next week.
• Private Network Access is needed. Yes this is a required dependency.
• https://github.com/annevk/orb is needed. I agree.

---

Also had a question about how this works for navigations. It seems to me that if the parent document has cors-or-credentialless, the child can have either that or require-corp. But if the parent has require-corp, the child shouldn't be allowed to have cors-or-credentialless perhaps as that's weaker? (Especially once most things cross-origin are without credentials anyway.)

For now, the HTML spec PR and tentative test puts require-corp and cors-or-credentialless at the same level. One can embed the other and vice-versa. I initially thought require-corp couldn't embed cors-or-credentialless, because I felt one was weaker than than other. However, I couldn't really tell what was the threat this would protect us from. If you can find any potential reason to restrict this, feel free to share.

[annevk]

require-corp also offers CORS as alternative without explicitly mentioning it. So I think it would be nicer to be consistent with that, naming-wise.

I think require-corp is stricter as there are less resources it would end up embedding and there's a class of IP-authenticated resources we know credentialless cannot protect. However, like you, I cannot come up with a credible threat. (I'm a bit surprised that above you say there is no solution for iframe yet. It seems that is somewhat critical and also relevant to this issue.)

[ArthurSonzogni]

require-corp also offers CORS as alternative without explicitly mentioning it. So I think it would be nicer to be consistent with that, naming-wise.

I understand this argument. cors-or-credentialless would be easier to understand for users, but this would have required require-corp to be for instance cors-or-corp, for consistency.
I don't have a strong opinion for one or the other. If others have different opinions, free to discuss this here or open a different issue. Otherwise, I guess we can switch toward COEP:credentialless.

I'm a bit surprised that above you say there is no solution for iframe yet. It seems that is somewhat critical and also relevant to this issue.

COEP:credentialless, doesn't relax <iframe> over the status co. They are still blocked if they don't use require-corp or credentialless.

@camillelamy will soon release an explainer for a potential solution to the deployment of <iframe> you don't control. The way it is built make it independent of COEP:credentialless.

[camillelamy]

So for iframes, we propose a separate solution via an iframe attribute. I have put together an explainer detailing the solution. This is separate from COEP: credentialless. We envision COEP: credentialless as an easy way to deploy COEP on first party frames that embed a lot of unpersonalized cross-origin subresources (e.g. images from a CDN).