Subject: [websec] Review of draft-ietf-websec-origin-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 May 2011 19:14:05 +0100

I agree that section marked TBD and missing references marked "[cite]" 
should be fixed. Additionally:

3.  Origin

   An origin represents a web principal.  Typically, user agents
   determine the origin of a piece of content from the URI from which
   they retrieved the content.  In this section, we define how to
   compute an origin from a URI.

   The origin of a URI is the value computed by the following algorithm:

   1.  If the URI does not use a server-based naming authority, or if
       the URI is not an absolute URI, then return a globally unique
       identifier.

Does this cover URI schemes like "mailto" and "about"? I am not sure 
that the term "server-based naming authority" is specified anywhere.

   2.  Let uri-scheme be the scheme component of the URI, converted to
       lowercase.

   3.  If the implementation doesn't support the protocol given by uri-
       scheme, then return a globally unique identifier.

 [...]

   5.  Let uri-host be the idna-canonicalization of the host component
       of the URI.

   6.  If there is no port component of the URI:

If mailto/about or the like are not covered above, then 5/6 are a problem.

   7.  Return the triple (uri-scheme, uri-host, uri-port).

Should the username part be included as well, if allowed/used by the URI 
scheme?

6.3.  User Agent Requirements

   o  The value of the Origin header MUST be either:

      *  The string "null" (i.e., the byte sequence %x6E, %x75, %x6C,
         %x6C).

      *  The value of the Origin header in the previous-request.  The
         user agent MUST NOT choose this option if the ascii-
         serialization of previous-uri is not identical to the last
         serialized-origin in the Origin header of the previous request.

      *  The value of the Origin header in previous header extended with
         a space and the ascii-serialization of the origin of previous-
         uri.  The user agent MUST NOT choose this option if the ascii-
         serialization of the origin of previous-uri is "null".

Regarding the last sentence: what should be done in this case?It doesn't 
look like the previous quoted paragraph covers this alternative.

I actually found the 3 choices to be confusing. Maybe an example 
demonstrating each case would help?