same-site |Re: Formalizing the HTTP State Tokens proposal.

Follow-up:

Delivery scope "same-site" should be same definition
on "same-siteness" than 

5.2.  "Same-site" and "cross-site" Requests
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.2

gives. But now it is not.  It is confusing when two releted technology
uses different definition.

( SameSite is already implemented by browsers )


( continuing inline )

> 3.2.  Requests and Responses
> https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-3.2
> 
> |   This document relies upon the definitions of "request" and "response"
> |   found in [Fetch].
> |
> |   A request's delivery scope can be obtained as follows:
> |
> |   1.  Let "request-origin" be the request's "origin", and "target-
> |       origin" be the request's "URL"'s "origin".
> |
> |   2.  If the request was generated by the user agent as a response to
> |       direct user interaction with the user agent (e.g. the user typed
> |       an address into the agent's address bar, clicked a bookmark, or
> |       etc.), return "same-origin".
> |
> |   3.  If "request-origin" is same-origin with "target-origin", return
> |       "same-origin".
> |
> |   4.  If "request-origin"'s registrable domain is the same as "target-
> |       origin"'s registrable domain, return "same-site".

      I think that should be named "same-domain" so that it does not
      confuse "same-site" request definition for SameSite cookies
      (it uses "site for cookies").

      Use "same-site" term for request's delivery scope only
      if client's "site for cookies" (as defined for SameSite)
      is the same as "target-origin"'s registrable domain.

> |   5.  Return "cross-site".
> 
> 
> Is delivery=same-site intended to cause Sec-Http-State request field
> to be send about same requests than Cookies with SameSite attribute?
> 
> SameSite seems use definition "site for cookies" for that. How that
> compare to "request-origin" ?

"site for cookies" is different than "request-origin"

That is effectively

https://html.spec.whatwg.org/multipage/origin.html#origin

| If the Document's URL's scheme is a network scheme
|
|    A copy of the Document's URL's origin assigned when the Document is created.
|
|    The document.open() method can change the Document's URL to "about:blank". Therefore the origin is assigned when the Document is created.


> 5.2.  "Same-site" and "cross-site" Requests
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.2
> 
> |   2.  Let "site" be "request"'s client's "site for cookies" (as defined
> |       in the following sections).
> |
> |   3.  Let "target" be the registered domain of "request"'s current url.
> |
> |   4.  If "site" is an exact match for "target", return "same-site".
> 
> 5.2.1.  Document-based requests
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.2.1
> 
> |   For a document displayed in a top-level browsing context, we can stop
> |   here: the document's "site for cookies" is the top-level site.
> 
>  (and so on)

 https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.2.1

specially:

| 5.2.1.  Document-based requests
| 
|   The URI displayed in a user agent's address bar is the only security
|   context directly exposed to users, and therefore the only signal
|   users can reasonably rely upon to determine whether or not they trust
|   a particular website.  The registered domain of that URI's origin
|   represents the context in which a user most likely believes
|   themselves to be interacting.  We'll label this domain the "top-level
|   site".
|
|   For a document displayed in a top-level browsing context, we can stop
|   here: the document's "site for cookies" is the top-level site.
|
|   For documents which are displayed in nested browsing contexts, we
|   need to audit the origins of each of a document's ancestor browsing
|   contexts' active documents in order to account for the "multiple-
|   nested scenarios" described in Section 4 of [RFC7034].  These
|   document's "site for cookies" is the top-level site if and only if
|   the document and each of its ancestor documents' origins have the
|   same registered domain as the top-level site.  Otherwise its "site
|   for cookies" is the empty string.

 
> 
> I failed interpret how Fetch defines request's "origin"
> 
> https://fetch.spec.whatwg.org/#concept-request-origin
> 
> https://html.spec.whatwg.org/multipage/origin.html#concept-origin
> 
> 
> Specially nested browsing contexts (iframes and so on). 
 
/ Kari Hurtta

Received on Sunday, 7 April 2019 17:10:32 UTC