Subject: Re: Defining First and Third Party Cookies

From: Julian Reschke <[email-masked]>
Date: Wed, 20 Jul 2016 08:16:43 +0200

On 2016-03-03 12:10, Anne van Kesteren wrote:
> On Mon, Feb 22, 2016 at 1:45 PM, Mike West <[email-masked]> wrote:
>> I think we need precision somewhere. I'm fairly agnostic about where that
>> somewhere might be. Adding Anne, who might be interested in defining terms
>> like these in Fetch?
>
> Seems fine. (Though note that the Origin RFC comparison does not quite
> fly, it's made obsolete by the combination of HTML, Fetch, and URL
> Standards.)

So, out of curiosity: what *exactly* should a spec cite now when it 
talks about origins (and is that actually compatible with RFC 6454)?

Best regards, Julian

---

From: [email-masked]
Date: Wed, 20 Jul 2016 00:33:27 -0600

> talks about origins (and is that actually compatible with RFC 6454)?

good question :)

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 20 Jul 2016 09:59:51 +0200

On Wed, Jul 20, 2016 at 8:16 AM, Julian Reschke <[email-masked]> wrote:
> So, out of curiosity: what *exactly* should a spec cite now when it talks
> about origins (and is that actually compatible with RFC 6454)?

It really depends on which origin. Origin as a concept is defined by
HTML: https://html.spec.whatwg.org/multipage/browsers.html#origin.
Computing an origin from a URL is defined by URL:
https://url.spec.whatwg.org/#origin (you'll see it has a dependency on
HTML for that). Origin as an HTTP header is defined by Fetch:
https://fetch.spec.whatwg.org/#origin-header.

-- 
https://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Jul 2016 11:36:29 +0200

Anne,

thanks for the feedback.

On 2016-07-20 09:59, Anne van Kesteren wrote:
> ...

It seems to me that RFC 6454 has much more text explaining origins and 
the same-origin policy. Is that somewhere in the HTML spec as well?

Other than that I notice that the definition of an origin changed to 
include one additional component ("domain"), which is optional and seems 
to be specific to browser APIs.

I can see why this stuff is needed internally in the browser spec, but 
I'm skeptic about this needing to "obsolete" RFC 6454.

> https://fetch.spec.whatwg.org/#origin-header.

Which attempts to make an incompatible change to the syntax of the 
header field. 
<https://github.com/w3c/resource-timing/issues/62#issuecomment-234105413> 
seems to indicate that this change would make Chrome and Edge non-compliant.

Best regards, Julian

---

From: Anne van Kesteren <[email-masked]>
Date: Fri, 22 Jul 2016 11:44:07 +0200

On Fri, Jul 22, 2016 at 11:36 AM, Julian Reschke <[email-masked]> wrote:
> It seems to me that RFC 6454 has much more text explaining origins and the
> same-origin policy. Is that somewhere in the HTML spec as well?

I'm not sure. I guess it's fine to use the RFC for some non-normative guidance.

> Other than that I notice that the definition of an origin changed to include
> one additional component ("domain"), which is optional and seems to be
> specific to browser APIs.

Yup.

> I can see why this stuff is needed internally in the browser spec, but I'm
> skeptic about this needing to "obsolete" RFC 6454.

Well, it's that concept of origin that's passed around. Other than
browsers there's not much use for origins.

> Which attempts to make an incompatible change to the syntax of the header
> field.

Only for that particular header, if that particular header continues
to use that syntax. If they do however, they'd be wise to introduce
their own production and not pretend it's the same as what's used for
Origin, since that'd be false.