The Web Origin Concept
Note: This ballot was opened for revision 06 and is now closed.
(Peter Saint-Andre) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Wesley Eddy) (was Discuss) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
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.
(Russ Housley) No Objection
Comment (2011-09-21 for -** No value found for 'p.get_dochistory.rev' **)
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.