Subject: Cookies: Integration with external specs.

From: Mike West <[email-masked]>
Date: Mon, 18 Jan 2016 10:09:06 +0100

While we have the cookies spec open, I think we should take a closer look
at how that specification interacts with others. In particular, two things
come to mind:

* We should formalize the integration with Fetch (see step 11.1 of
https://fetch.spec.whatwg.org/#http-network-or-cache-fetch and 9.3 of
https://fetch.spec.whatwg.org/#http-network-fetch).

* https://w3c.github.io/webappsec-csp/cookies/ defines a scoping mechanism
for `document.cookies` and `Set-Cookie` via a monkey-patch to the RFC.
Putting some sort of generic policy hook into the document (either via
explicit dependencies, as in that document, or via some sort of registry of
delegates) seems valuable.

What do you folks think?

-mike

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jan 2016 11:14:47 +1100

Hey Mike,

On 18 Jan 2016, at 8:09 pm, Mike West <[email-masked]> wrote:
> 
> While we have the cookies spec open, I think we should take a closer look at how that specification interacts with others. In particular, two things come to mind:
> 
> * We should formalize the integration with Fetch (see step 11.1 of https://fetch.spec.whatwg.org/#http-network-or-cache-fetch and 9.3 of https://fetch.spec.whatwg.org/#http-network-fetch).

What changes in the RFC would be necessary to do this?

> * https://w3c.github.io/webappsec-csp/cookies/ defines a scoping mechanism for `document.cookies` and `Set-Cookie` via a monkey-patch to the RFC. Putting some sort of generic policy hook into the document (either via explicit dependencies, as in that document, or via some sort of registry of delegates) seems valuable.

That seems pretty reasonable to me. What do others think? In particular, would people like to see an I-D spelling the changes out, or is <https://w3c.github.io/webappsec-csp/cookies/#monkey-patching-rfc6264> sufficiently precise?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mike West <[email-masked]>
Date: Tue, 19 Jan 2016 09:52:20 +0100

On Tue, Jan 19, 2016 at 1:14 AM, Mark Nottingham <[email-masked]> wrote:

> > While we have the cookies spec open, I think we should take a closer
> look at how that specification interacts with others. In particular, two
> things come to mind:
> >

This would boil down to:

* a light refactoring of https://tools.ietf.org/html/rfc6265#section-5.2
away from "When the user agent receives a Set-Cookie header field in an
HTTP response", towards something more like a "Process a `Set-Cookie`
header" algorithm that Fetch can pass the header value into explicitly.

* A thin shim on top of the "cookie string" algorithm that actually sets
the header for a Request. This could live in Fetch, I suppose, but seems
better positioned in the Cookie spec.

I can put together a brief I-D spelling out these changes.

-mike

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Jan 2016 15:25:55 +1100

> On 19 Jan 2016, at 7:52 pm, Mike West <[email-masked]> wrote:
> 
> * a light refactoring of https://tools.ietf.org/html/rfc6265#section-5.2 away from "When the user agent receives a Set-Cookie header field in an HTTP response", towards something more like a "Process a `Set-Cookie` header" algorithm that Fetch can pass the header value into explicitly.
> 
> * A thin shim on top of the "cookie string" algorithm that actually sets the header for a Request. This could live in Fetch, I suppose, but seems better positioned in the Cookie spec.
> 

Please.