The Web Origin Concept
RFC 6454

  The Gen-ART Review by Miguel Garcia on 5-Sep-2011 raised a few minor
  concerns, and they were addressed by the authors.  However, a new
  version of the document with the suggested changes gas not been 
  posted yet.

There are quite a few places where the language used here is
difficult or problematic. I'd encourage the authors to consider
including fewer words if possible - a lot of the descriptive
material isn't really necessary and the document might be better
without it. 

- 2.2: "OWS SHOULD either not be produced or be produced as a single
SP character." is a bit unclear. Why not say that user agents MUST
be able to handle OWS as input, but SHOULD just produce a single SP
on output?

- 2.3: The definition of "globally unique identifier" is odd if you
don't have some kind of hierarchy/registration scheme. I think all
you need here is a low probability of collision and it'd be better
to be explicit about that so that implementations don't choose
over-short identifiers (not everyone understands the birthday
paradox).

- 2.3: a couple of examples of idna-canonicalized host names would
help here if you have them. People might easily go wrong in the
conversion otherwise given how many RFCs are referenced in the
definition.

- Section 3: I think it'd be good to point out here that there have
been variations in what is called a "same origin policy" - referring
to "*the* same origin policy" hides that issue.

- 3.1: "Trust" is a horrible term when not qualified and tends to be
interpreted differently by different people.  I think this'd be
better if the term wasn't used at all.  Perhaps you could recast
this section as "things for which URIs are used by UAs" and get rid
of the word "trust" entirely, e.g. in the 1st example, the document
author is assuming that the right content will be fetched when the
script URI is de-referenced etc. 

- 3.1: "execute the script with the privileges of the document"
seems wrong - the document doesn't have privileges associated with
it, rather the context in which the document is being rendered in
the UA has associated privileges, granted by the user, UA and client
OS. The term used could mislead someone into thinking that the
document will always have the same privileges regardless of UA
which'd be wrong.

- 3.1: Saying "the document exports *its* secret data..." seems
wrong - it's the user's secret, not the document's.  Saying the
"document...trusts the confidentiality of information sent" also
seems wrong.  

- 3.1.1: What if relative URIs are used? Are you saying not to do
that? Can't that be a (worse) pitfall?

- 3.2: example.edu is not one of the example domains afaik.  (Maybe
it ought be, but I don't think it is.)

- 3.3: The term authority is being defined here with a novel
meaning. I think you need to call that out in section 2.3. I also
wonder at the definition. Saying that an image is passive seems
wrong (.wmf, .tiff etc have all seen vulnerability reports) and
it seems to wrongly conflate the media type with the privileges with
which the UA renders the content. Section 3.4.2 also seems to argue
against associating privileges with media types and says that one
should associate them with origins. This is fairly confused stuff.

- 3.5: You could/should drop the word "trust" as per the comment
above.

- section 4: typos: "Other user agent use a globally unique
identifier each file URI, which is the most secure option." above
IMO." s/agent/agents/ & s/each file/for each file/

- 3.3: typo "User agent determine" s/agent/agents/

- section 4, last para: I see no point in saying "Implementations
MAY define other types of origins" without saying what those might
be in sufficient detail that two implementations (of this spec)
would do the same thing. Suggest getting rid of the paragraph.

- section 4: It seems to me that you don't actually need global
uniqueness at all but rather just local uniqueness in the scope of a
single "run" of the UA. I don't object to being OTT in this respect
but it'd be better if you made it clear that even though you only
need local uniqueness right now, you're asking for more than that,
just in case.

- 7.1: I don't get why you have section 6 define how to serialise
but then don't use that in the syntax here.  That is, the "://"
catentation is re-done in 7.1.

- 7.2: Why say "might wish to" and not MAY here? If >1 origin is
involved and a UA is going to send out an Origin header, then I
don't get why there isn't a MUST for including all origins.

- section 8: references for taint-tracking and exfiltration would be
good - those are not common terms.

- 8.2: "NOT RECOMMENDED" is missing from 2119 unfortunately.

- 8.2: typo s/domain a function/domain is a function/

- 8.2 - what URI scheme uses public keys for naming authorities?
Giving an example of a registered scheme that does that would 
be good.

- 8.2 - typo: s/at worse/at worst/

- 8.3: "objects which the content is able to designate" is hard to
understand or meaningless. I'm not quite sure what you do mean
exactly though. The entire section is hard to understand actually.

- Section 10: the section header could be deleted since only 10.1
has content.