- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 16 Aug 2018 19:42:53 +1000
- To: Mike West <mkwst@google.com>
- Cc: Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Aug 16, 2018 at 7:29 PM Mike West <mkwst@google.com> wrote: >> So, if I'm visiting a page on example.com, the default behaviour would >> be to have the token delivered in requests to example.com. >> Subresources loaded on the same page would - by default - have no >> associated token? Or the token associated with that origin? And if >> the site said "cross-site" in a response, then the token would be >> attached to all subresource requests? > > > In a browser context, when a user navigates to `https://example.com/`: > > * The navigational request would include `https://example.com`'s token. > * Requests to `https://example.com/` would include `https://example.com`'s token. > * Requests to `https://sub.example.com/` would include `https://sub.example.com`'s token, unless it had opted-into `same-origin` delivery (in which case it would be excluded). > * Requests to `https://not-example.com/` would include `https://not-example.com`'s token iff it had opted-into `cross-site` delivery. OK, I misunderstood who was opting in. Thanks. I suspect that some of the cross-site options here might be blocked by browser policy (double-keying). > What means are you thinking of? Cookies? GET parameters? In the context you are talking about, GET and service workers primarily. (If the goal is to progressively neuter cookies, then we can't start to rely on them more.)
Received on Thursday, 16 August 2018 09:43:29 UTC