Add `credentialless` value to COEP (HTML spec) by ArthurSonzogni · Pull Request #6638 · whatwg/html

ArthurSonzogni · 2021-04-30T12:35:25Z

Originally described in: https://github.com/mikewest/credentiallessness

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

HTML (Add credentialless value to COEP (HTML spec) #6638)
- Define how to parse the credentialless value.
- From the HTML spec point of view, credentialless and require-corp are equivalent. They have been grouped into compatible with cross-origin isolation and the HTML spec rewritten to use this concept.
Fetch: (Specify the behavior of COEP: credentialless, fetch#1229)
- Define Cross-Origin-Embedder-Policy allows credentials algorithm. It omit credentials for no-cors, cross-origin, COEP:credentialless requests.
- Define response's request-include-credentials flag.
- In the Cross-Origin-Resource-Policy check, if embedderPolicy is credentialless, require CORP for navigational responses, and opaque responses with request-include-credentials.

See: #6637

At least two implementers are interested (and none opposed):
- Chrome: https://chromestatus.com/feature/4918234241302528#details
- Firefox: COEP: credentialless mozilla/standards-positions#539 (worth prototyping)
- Safari: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html (pending)
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/html/cross-origin-embedder-policy/credentialless
Implementation bugs are filed:
- Chrome: https://crbug.com/1175099
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1731778
- Safari: https://bugs.webkit.org/show_bug.cgi?id=230550

(See WHATWG Working Mode: Changes for more details.)

See: #6637

/browsers.html ( diff )
/origin.html ( diff )
/workers.html ( diff )

ghost · 2021-04-30T12:43:26Z

This is still work in progress.

I still need write PR for fetch and ServiceWorker. Those will be more interesting.
Happy to get early feedback if you have in the meantime nevertheless.

@whatwg/cross-origin-isolation @antosart @mikewest @camillelamy @iVanlIsh

ghost · 2021-06-07T12:53:59Z

I am happy with the spec.
I wrote page gathering the two PR in a single page if you want to have a broader view:
https://htmlpreview.github.io/?https://github.com/mikewest/credentiallessness/blob/master/index.html

Would you have some suggestion?

ghost

Normatively this is looking good! A number of style and clarity suggestions:

ghost · 2021-06-10T21:45:48Z

+   <dt>"<dfn data-x="coep-credentialless" export for="embedder policy value"><code
+   data-x="">credentialless</code></dfn>"</dt>
+   <dd><p>When this value is used, fetching cross-origin no-CORS resources omits credentials. In
+   exchange, an explicit `<code>Cross-Origin-Resource-Policy</code>` on response is not required.


Maybe this should be more general and talk about explicit server permission, to cover CORS as well (like the next bullet pointed does)?

Maybe sometime like:

When this value is used, fetching cross-origin no-CORS resources omits credentials and don't require an explicit `Cross-Origin-Resource-Policy` header. The other requests sent with credentials requires the server's explicit permission through the CORS protocol or the `Cross-Origin-Resource-Policy` header.

?

Sounds good, although "The Other" requests seems a bit confusing. Maybe

Other requests are sent with credentials, and require the server's....

?

ghost · 2021-06-10T21:46:38Z

-    <p>If <var>parsedItem</var> is non-null and <var>parsedItem</var>[0] is "<code
-    data-x="">require-corp</code>":</p>
-
+   <li><p>If <var>parsedItem</var> is non-null</p>


Colon before , and follow the previous pattern for how the  is linebreaked and positioned relative to the <li>

I believe I addressed this comment, but it wasn't fully clear to me. Please double check.

ghost · 2021-06-10T21:46:56Z

-     <li><p>Set <var>policy</var>'s <span data-x="embedder-policy-value">value</span> to "<code
-     data-x="coep-require-corp">require-corp</code>".</p></li>.
+      <!--credentialless-->
+      <li><p>If <var>parsedItem</var>[0] is "<code data-x="">credentialless</code>":</p>


Indentation is off for both the  and <ol> here

Do you meant going from two space to one, right?

No. You have written

<li>... <ol> ... </ol>

whereas the prevailing style is

<li> ... <ol> ... </ol> </li>

I will push this in my fix.

ghost · 2021-06-10T21:51:05Z

Also I'm a bit confused on whether we landed on credentialless or cors-or-credentialless...

ghost

Thanks you Domenic,
I addressed your comments below:

ghost · 2021-06-11T07:10:57Z

+   <dt>"<dfn data-x="coep-credentialless" export for="embedder policy value"><code
+   data-x="">credentialless</code></dfn>"</dt>
+   <dd><p>When this value is used, fetching cross-origin no-CORS resources omits credentials. In
+   exchange, an explicit `<code>Cross-Origin-Resource-Policy</code>` on response is not required.


Maybe sometime like:

When this value is used, fetching cross-origin no-CORS resources omits credentials and don't require an explicit `Cross-Origin-Resource-Policy` header. The other requests sent with credentials requires the server's explicit permission through the CORS protocol or the `Cross-Origin-Resource-Policy` header.

?

ghost · 2021-06-11T07:15:38Z

-    <p>If <var>parsedItem</var> is non-null and <var>parsedItem</var>[0] is "<code
-    data-x="">require-corp</code>":</p>
-
+   <li><p>If <var>parsedItem</var> is non-null</p>


I believe I addressed this comment, but it wasn't fully clear to me. Please double check.

ghost · 2021-06-11T07:17:10Z

-     <li><p>Set <var>policy</var>'s <span data-x="embedder-policy-value">value</span> to "<code
-     data-x="coep-require-corp">require-corp</code>".</p></li>.
+      <!--credentialless-->
+      <li><p>If <var>parsedItem</var>[0] is "<code data-x="">credentialless</code>":</p>


Do you meant going from two space to one, right?

ghost

I pushed a commit with the whitespace fixes; please take a look for next time. Overall this LGTM modulo our discussion on the phrasing of how "credentialless" is explained.

ghost · 2021-06-11T15:49:44Z

-    data-x=""><span>Cross-Origin-Embedder-Policy</span>: <span
-    data-x="coep-require-corp">require-corp</span></code>`.</p></li>
+    <li><p>every <span>Document</span> has a `<code data-x="embedder policy value">
+    Cross-Origin-Embedder-Policy</code> value <span>compatible with cross-origin isolation</span>.


More line-breaking and whitespace problems. Note how adding a newline and spaces before Cross makes a visible space in the output, which is undesirable. The same for adding a newline and space before .

This reoccurs several times in the PR.

I will push a commit fixing this and other such problems, but please take a look at the diff I upload so that it's clearer in the future how to avoid such problems in the output.

Hmm, my editor (vim) is able to correctly insert new lines to the right locations, including in the location you fixed if I remove the additional spaces. There must be some unknown (yet) cause to this in my editor. Next time I should stop relying on tooling and verify manually every new lines are correct. I didn't realized this. Thanks for the fix!

ghost · 2021-06-11T15:52:05Z

+   <dt>"<dfn data-x="coep-credentialless" export for="embedder policy value"><code
+   data-x="">credentialless</code></dfn>"</dt>
+   <dd><p>When this value is used, fetching cross-origin no-CORS resources omits credentials. In
+   exchange, an explicit `<code>Cross-Origin-Resource-Policy</code>` on response is not required.


Sounds good, although "The Other" requests seems a bit confusing. Maybe

Other requests are sent with credentials, and require the server's....

?

ghost · 2021-06-11T15:54:01Z

-     <li><p>Set <var>policy</var>'s <span data-x="embedder-policy-value">value</span> to "<code
-     data-x="coep-require-corp">require-corp</code>".</p></li>.
+      <!--credentialless-->
+      <li><p>If <var>parsedItem</var>[0] is "<code data-x="">credentialless</code>":</p>


No. You have written

<li>... <ol> ... </ol>

whereas the prevailing style is

<li> ... <ol> ... </ol> </li>

I will push this in my fix.

ghost · 2021-06-11T16:53:07Z

Thank you!

Sounds good, although "The Other" requests seems a bit confusing. Maybe

Fixed in f04b0dc

ghost · 2021-09-07T09:06:55Z

At the moment, we are evaluating shipping it in Chrome M96 based on the feedback we've got so far. Please let me know if you have any objections.

Until a second web browser is interested implementing it, this will have to stay as two indefinitely open PRs for fetch and HTML + one monkey-patch summarizing the two.

ghost · 2021-09-13T10:48:17Z

I'm not sure how many other changes are contemplated in this area, but I would be okay with landing this to ease maintenance. However, I do think we should add an implementer warning alongside this value that PNA and ORB are strongly encouraged to be supported in some form.

ghost · 2021-09-13T12:35:03Z

I rebased without conflict, and added in the latest commit the warning:

I'm not sure how many other changes are contemplated in this area, but I would be okay with landing this to ease maintenance.

This would encompass this change and the one in Fetch:

ghost · 2021-09-14T08:31:07Z

That looks good to me. I have some concerns about the Fetch PR (noted there). The Fetch PR also notes the need for a SW PR which I recall discussing at some point. Is that ready?

ghost · 2021-09-14T10:03:30Z

Thanks @annevk . I will take a look at the Fetch PR.

The Fetch PR also notes the need for a SW PR which I recall discussing at some point. Is that ready?

At the end, there was no SW PR. It was resolved in Fetch only.

See:
w3c/ServiceWorker#1592
The issue was about sending responses using CacheStorage/SW in between two environments with different COEP policies.

The resolution was modifying the CORP check in the Fetch specification.
When the client is using COEP:credentialless, we require CORP when:

Request made with credentials (<- the important part)
Navigation requests.

ghost · 2021-09-21T16:15:18Z

So Mozilla committed to implement this?
This adds quite a bit of complexity to another already very complex feature.

ghost · 2021-09-21T16:20:14Z

Yeah agreed. We are reluctant and it's conditional upon ORB/PNA working out, but this would ease adoption quite a bit. I do think more pressure could be put on sites to adopt COOP/COEP as-is though.

ghost · 2021-09-21T16:29:45Z

Even though we recently implemented COOP/COEP in WebKit, I have no plan to add support for credentialless at the moment. It adds too much complexity and seems to have quite a few dependencies.

ghost · 2021-09-21T16:33:02Z

This adds quite a bit of complexity.

COEP:credentialless on its own is very lightweight. It can be implemented quickly in 3 steps:

Conditionally set to false includeCredential boolean in the fetch algorithm.
Add a case in the CORP check. Useful when moving a response in between two environment with different COEP policy.
In most places, replace "COEP == require-corp" into "COEP == (require-corp | credentialless)".

However, implementing the dependencies: Private Network Access and ORB is indeed not trivial.

Note that it works independently from anonymous iframe, which doesn't really exist yet. I don't count this as a dependency. I added a comment on the webkit bug I opened today.

ghost · 2021-09-21T17:03:42Z

The argument about added complexity is reasonable, but I just wanted to note that there are substantial adoption benefits associated with COEP:credentiallless. Namely, while applications can in principle use COEP require-corp to enable cross-origin isolation, the requirement to ensure that every loaded resource explicitly opts in (via CORP or CORS) results in a large number of blocking issues that prevent developers from using COEP in most non-trivial applications.

For WebKit specifically, I wonder if the fact that it disables 3p cookies is an advantage in this context. As in, WebKit already sends cross-site requests as effectively credentialless, which aligns very well with the goal here -- this significantly reduces the risk associated with not implementing PNA/ORB. (Though note that same-site requests can still be a concern.)

ghost · 2021-09-22T07:37:31Z

No, it does not reduce the risk. The risk was never with CORS requests. The risk of credentialless without PNA/ORB is entirely about resources behind firewalls of sorts.

ghost

Overall this looks solid, but I found a number of typos and also have some suggestions for light refactoring.

ghost · 2021-09-28T10:20:20Z

   <li>
    <p>If <var>parsedItem</var> is non-null and <var>parsedItem</var>[0] is "<code
-    data-x="">require-corp</code>":</p>
+    data-x="">credentialless</code>" or "<code data-x="">require-corp</code>":</p>


Can we use compatible with cross-origin isolation here? Perhaps we should not have "embedder policy value" as a type? And just make it a string. That would also help with the next step.

I feel using "compatible with cross-origin isolation" here would be a misfit, since its goal is to discriminate the COEP values bringing (potentially) the COI capability from the other. Here, this is a parser and we just want to filter valid string value.

Yes, for now, they both correspond to the same set (% string vs enum). If you don't feel too strongly about this, I would prefer not to change this.

If I were to refactor this I'd do away with the dedicated "embedder policy value" and reuse "compatible" here (it being a simple list of things) as I'm not really convinced it helps to have to maintain that list in multiple places.

Also, in the very next step you give up on the pretense that there is some distinction by setting the policy value directly to the parsed value.

That second thing especially makes me think the current setup isn't sound and just making everything be strings would be easier.

What do you think?

I feel I am not fully understanding your previous comment. Also, I am not fully sure how you would like me to make COEP's value to be of string type.
I gave it a try in:
815311b
Is it what you wanted?

ghost · 2021-10-06T13:57:10Z

Thanks @annevk! I addressed the suggestions from your last review (+ one unresolved). Sorry for the delay, I didn't see your review immediately.

ghost

Sorry, I thought we were done, but upon rereading I found more nits and including somewhat substantive nits.

ghost · 2021-10-11T11:39:29Z

   <li>
    <p>If <var>parsedItem</var> is non-null and <var>parsedItem</var>[0] is "<code
-    data-x="">require-corp</code>":</p>
+    data-x="">credentialless</code>" or "<code data-x="">require-corp</code>":</p>


If I were to refactor this I'd do away with the dedicated "embedder policy value" and reuse "compatible" here (it being a simple list of things) as I'm not really convinced it helps to have to maintain that list in multiple places.

Also, in the very next step you give up on the pretense that there is some distinction by setting the policy value directly to the parsed value.

That second thing especially makes me think the current setup isn't sound and just making everything be strings would be easier.

What do you think?

ghost

Thanks Anne!
I addressed you comment with the latest 2 additional commit.

ghost · 2021-10-13T16:32:00Z

   <li>
    <p>If <var>parsedItem</var> is non-null and <var>parsedItem</var>[0] is "<code
-    data-x="">require-corp</code>":</p>
+    data-x="">credentialless</code>" or "<code data-x="">require-corp</code>":</p>


I feel I am not fully understanding your previous comment. Also, I am not fully sure how you would like me to make COEP's value to be of string type.
I gave it a try in:
815311b
Is it what you wanted?

ghost · 2021-10-13T16:42:03Z

         <li>
          <p>If <var>sandboxFlags</var> is not empty and <var>responseCOOP</var>'s <span
-          data-x="coop-struct-value">value</span> is not "<code
-          data-x="coop-unsafe-none">unsafe-none</code>", then set <var>response</var> to an


Self suggestion: This has nothing to do with COEP. Revert this part.

ghost

Apologies, I was thinking we could do away with "embedder policy value" as a concept altogether, but it seems we need it as two members take it, so it's useful to have as an abstraction.

I'd appreciate it if @domenic or someone else can take another look as well given the back-and-forth thus far. Makes it easy to overlook something.

ghost · 2021-10-18T12:08:47Z

+    <li><p>every <span>Document</span> has a `<code data-x="embedder policy
+    value">Cross-Origin-Embedder-Policy</code>' header whose <span
+    data-x="embedder-policy-value">value</span> is <span>compatible with cross-origin
+    isolation</span>.</p></li>


The header name should end with ` not '.

The header name should not xref embedder policy.

When you talk about the header value it should not xref embedder policy value either. You can reference the value definition for header in Fetch, but I don't think that's really needed.

1: Done in 0bb1a99.

2 & 3: Done in 0bb1a99. I removed the data-x for both the header name and value. However I have no idea when we should and we shouldn't I naively thought adding it every time was best. I will follow you blindly here, but if you can explain why, that would allow me to do it better next time.

It might be easier if you could join https://whatwg.org/chat so we can discuss this more synchronously as I'm not entirely sure where the confusion lies. The problem with the data-x value that you added here is that it's not for the definition of the header or the definition of a header's value member. The header links just fine without a data-x and word "value" would have to link to https://fetch.spec.whatwg.org/#concept-header-value if anything.

ghost · 2021-10-18T12:09:02Z

+    data-x="coop-same-origin">same-origin</span></code>` and a `<code data-x="embedder policy
+    value">Cross-Origin-Embedder-Policy</code>` whose <span
+    data-x="embedder-policy-value">value</span> is <span>compatible with cross-origin
+    isolation</span> together.<p>


Similar comments applicable here.

Done in 0bb1a99.
However, I don't really understand why we do this for COEP and not for COOP on the same sentence.

Well, you're not changing COOP but also for COOP we can list the header-value construct as a single thing (and have done so), but that's no longer possible for COEP as multiple values are okay now.

Hope that helps.

Define COEP:credentialless Originally described in: https://github.com/mikewest/credentiallessness `credentialless` and `require-corp` are similar. One or the other is a requirements for the `window.crossOriginIsolated` capability. They differ mostly in the fetch specification. `require-corp` requires a CORP header for cross-origin no-cors responses. `credentialless` doesn't, but omits credentials (Cookies, clients certificates, etc...) in the request. * HTML (whatwg#6638) * Define how to parse the `credentialless` value. * From the HTML spec point of view, `credentialless` and `require-corp` are equivalent. They have been grouped into `compatible with cross-origin isolation` and the HTML spec rewritten to use this concept. * Fetch: (whatwg/fetch#1229) * Define `Cross-Origin-Embedder-Policy allows credentials` algorithm. It omit credentials for no-cors, cross-origin, COEP:credentialless requests. * Define `response's` `request-include-credentials` flag. * In the `Cross-Origin-Resource-Policy check`, if `embedderPolicy` is `credentialless`, require CORP for navigational responses, and opaque responses with `request-include-credentials`. See: whatwg#6637 ---- - [ ] At least two implementers are interested (and none opposed): * Chrome: https://chromestatus.com/feature/4918234241302528#details * Firefox: mozilla/standards-positions#539 (worth prototyping) * Safari: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html (pending) - [X] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at: * https://wpt.fyi/results/html/cross-origin-embedder-policy/credentialless - [X] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed: * Chrome: https://crbug.com/1175099 * Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1731778 * Safari: https://bugs.webkit.org/show_bug.cgi?id=230550 (See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

ghost · 2021-10-20T11:52:38Z

Thanks Anne! I addressed your comments in 0bb1a99.
Now looking for @domenic for additional comments.

ghost

LGTM. Should we merge before or after whatwg/fetch#1229 ?

ghost · 2021-11-01T23:21:38Z

Thanks!

LGTM. Should we merge before or after whatwg/fetch#1229 ?

The fetch specification uses the exported credentialless value defined in the HTML specification. As a result, this one should be merged first.

ArthurSonzogni mentioned this pull request May 3, 2021

Specify the behavior of COEP: credentialless, whatwg/fetch#1229

Merged

3 tasks done

ArthurSonzogni force-pushed the cors-or-credentialless branch from cbb986b to df8e1ed Compare May 31, 2021 15:43

domenic reviewed Jun 10, 2021

View reviewed changes

ArthurSonzogni changed the title ~~Add cors-or-credentialless value to COEP (HTML spec)~~ Add credentialless value to COEP (HTML spec) Jun 11, 2021

ArthurSonzogni commented Jun 11, 2021

View reviewed changes

domenic approved these changes Jun 11, 2021

View reviewed changes

domenic force-pushed the main branch from 0947339 to 1b5099f Compare July 27, 2021 17:07

ArthurSonzogni force-pushed the cors-or-credentialless branch 2 times, most recently from f36c796 to 6bddeee Compare September 13, 2021 12:29

annevk reviewed Sep 28, 2021

View reviewed changes

annevk reviewed Oct 11, 2021

View reviewed changes

ArthurSonzogni commented Oct 13, 2021

View reviewed changes

annevk reviewed Oct 18, 2021

View reviewed changes

ArthurSonzogni force-pushed the cors-or-credentialless branch from 6f79635 to 9485456 Compare October 20, 2021 11:32

Address annevk@ comments.

0bb1a99

annevk reviewed Oct 22, 2021

View reviewed changes

Comment thread source Outdated

Editorial nits

e460199

domenic approved these changes Nov 1, 2021

View reviewed changes

domenic added addition/proposal New features or enhancements topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal labels Nov 1, 2021

final nit

62bc705

annevk merged commit 311934b into whatwg:main Nov 2, 2021

adamsilverstein mentioned this pull request Sep 28, 2026

Upstream Document-Isolation-Policy to HTML and Fetch WICG/document-isolation-policy#8

Open

Conversation

ArthurSonzogni commented Apr 30, 2021 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Apr 30, 2021

Uh oh!

ghost commented Jun 7, 2021

Uh oh!

ghost left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ghost Jun 10, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ghost Jun 10, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 10, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ghost commented Jun 10, 2021

Uh oh!

ghost left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ghost left a comment

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021 • edited by domenic Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021 • edited by ArthurSonzogni Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost Jun 11, 2021

Choose a reason for hiding this comment

Uh oh!

ghost commented Jun 11, 2021

Uh oh!

ArthurSonzogni commented Apr 30, 2021 •

edited by pr-preview Bot

Loading

ghost Jun 11, 2021 •

edited by domenic

Loading

ghost Jun 11, 2021 •

edited by ArthurSonzogni

Loading

ghost commented Sep 14, 2021 •

edited by ArthurSonzogni

Loading

ghost commented Sep 21, 2021 •

edited by ArthurSonzogni

Loading