The Web Origin Concept
RFC 6454

[Ballot discuss]
s3.1.1 points out that using RFC2617 could be problematic.  Is it worth deprecating it's use?  If that's a step to far adding something like "it is NOT RECOMMENDED that new protocols use concepts from [RFC2817]"?

[Ballot comment]
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.

[Ballot discuss]
The DISCUSS is in part based on the OPS-DIR review by Michael Sneed.

1.  (cleared)

2. Section 4 states:

>  Implementations MAY define other types of origins in addition to the
  scheme/host/port triple type defined above.  For example, an
  implementation might define an origin based on a public key or an
  implementation might append additional "sandbox" bits to a scheme/
  host/port triple.

However, both sections 6.1 and 6.2 define the values returned as serialization of origin in the case when the origin is not a scheme/host/port triple as "null" string. This seems contradictory.

[Ballot comment]
Section 2.3 - It seems like "globally unique identifier" and "idna-canonicalized host name" are better defined where they are used, especially since the latter is an algoritm and not really a definition of terminology.

Section 5 -

  o  Two origins that are globally unique identifiers cannot be the
      same if they were created at different times, even if they were
      created for the same URI.

Does "at different times" mean "in different HTML documents"? In other words, can't two identical URIs appearing in the same HTML match without worry of security problems?

[Ballot discuss]
Unlike other contexts, it seems to me that when it comes to matching origins, false positives are much worse than false negatives: The harm of false positives is that items will cross security contexts, hence compromising security, whereas false negatives simply mean that certain entities will not be able to request data on behalf of others. So, if two host names do not match because the hosts in question were using different versions of IDNA, or because a host name is not a valid label, better that they don't match rather than they do. So, I'm guessing you don't need to do any reference to RFC 3490 at all. Specifically:

Section 2.3 - In the definition of idna-canonicalized, I don't think you care if the labels are in fact NR-LDH labels or A-labels. If someone presents you with an all ASCII string, you'll lowercase it and use it for comparison, and if someone presents you with a string with non-ASCII-range Unicode, you'll want to punycode it and turn it into an ASCII string, even if it isn't a valid NR-LDH. But even if you do want valid NR-LDH labels, I think it would be actively bad to allow for 3490 NFKC canonicalization, because it would allow things to compare as identical that I'm guessing you really don't want, especially in this security context. So I think the choices are:

a) If you're willing to allow more false negatives, simply say, "If the label contains any non-ASCII-range Unicode characters, encode it with the algorithm defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all-ASCII label." And don't call it "idna-canonicalized", but instead call it "us-ascii-encoded".

b) If you're wanting to do some canonicalization, simply say, "If the label contains any non-ASCII-range Unicode characters, first normalize the string using NFC, and then encode it with the algorithm defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all-ASCII label."

I can find others to help tighten up the language if you go down this path.

Section 6.1 - There is no "ToUnicode" algorithm RFC 5891, so at the very least the paragraph is written incorrectly. But much of the 3490 ToUnicode algorithm is validating the label. I don't think there's a need to do the validation in this document. (Remember, if there are invalid *ASCII* host name labels -- like "example_host" -- the algorithm is not going to catch those, but nobody cares because it will only match another identical invalid label.) I would simply say: "For each label in the host part of the origin triple, if the label begins with "xn--" and the remainder of the label can be successfully decoded using the algorithm defined in RFC 3492 section 6.2, append the resulting Unicode label to the results. Otherwise, append the original label (including the "xn--", if any) to the results. Separate the labels with U+002E FULL STOP code points (".").

Section 10.1 - If the above two changes are made, this section can be eliminated.

[Ballot discuss]
The DISCUSS is in part based on the OPS-DIR review by Michael Sneed.

1. This document seems to cover Annex B in the websec WG charter, which specifically says:

> There also seems to be demand for a document that describes the
same-origin security model overall. However, it seems like that
document ought to be more informative rather than normative. The
working group may split draft-abarth-origin into separate informative
and standards track specifications, the former describing same-origin
security model, and the latter specifying the nuts-and-bolts of working
with origins (computing them from URLs, comparing them to each other,
etc).

I noticed that the language in the charter used a cautious 'may' but I am still wondering why the WG decided to keep the two parts in the same document. It looks to me that the definitions of  the "nuts and bolts" of comparing and serializing origins and of the Origin http header should have been normative and placed on the standards track.

2. Section 4 states:

>  Implementations MAY define other types of origins in addition to the
  scheme/host/port triple type defined above.  For example, an
  implementation might define an origin based on a public key or an
  implementation might append additional "sandbox" bits to a scheme/
  host/port triple.

However, both sections 6.1 and 6.2 define the values returned as serialization of origin in the case when the origin is not a scheme/host/port triple as "null" string. This seems contradictory.

[Ballot discuss]
The DISCUSS is in part based on the OPS-DIR review by Michael Sneed.

1. This document seems to cover Annex B in the websec WG charter, which specifically says:

> There also seems to be demand for a document that describes the
same-origin security model overall. However, it seems like that
document ought to be more informative rather than normative. The
working group may split draft-abarth-origin into separate informative
and standards track specifications, the former describing same-origin
security model, and the latter specifying the nuts-and-bolts of working
with origins (computing them from URLs, comparing them to each other,
etc).

I noticed that the language in the charter used a cautious 'may' but I am still wondering why the WG decided to keep the two parts in the same document. It looks to me that the definitions of  the "nuts and bolts" of comparing and serializing origins and of the Origin http header should have been normative and placed on the standards track.

2. Section 4 states:

>  Implementations MAY define other types of origins in addition to the
  scheme/host/port triple type defined above.  For example, an
  implementation might define an origin based on a public key or an
  implementation might append additional "sandbox" bits to a scheme/
  host/port triple.

However, both sections 6.1 and 6.2 defines values returned as serialization of origin in the case when the origin is not a scheme/host/port triple as "null" string. This seems contradictory.

[Ballot discuss]
(1) cleared

(2) Just saying "return a globally unique identifier" doesn't seem
enough. I think what you need is a new identifier for each run of
the algorithm. Section 5 depends on this, so you should say that in
section 4.

[Ballot comment]
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.

[Ballot discuss]
(1) Section 4: what if the uri scheme has no default port defined or
just doesn't include a port (e.g.  mailto) but is supported by the
implementation? What if the uri scheme has no host component?
Its not clear what should be returned for such cases and I think
it needs to be clear.

(2) Just saying "return a globally unique identifier" doesn't seem
enough. I think what you need is a new identifier for each run of
the algorithm. Section 5 depends on this, so you should say that in
section 4.

[Ballot discuss]
When section 4 says to return a "globally unique identifier", does it need to be generated based on the URI?  From the definition in section 2.3 it seems like you're supposed to just do a gensym, so it will be different every single time the origin is computed even for the same URI going through the algorithm at different times.  It wasn't clear to me if that was really the intent.

IANA understands that, upon approval of this document, there is a single
IANA Action that must be completed.

In the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

a new header field name will be added as follows:

Header field name: Origin
Protocol: http
Status:
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed
upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Web Origin Concept) to Proposed Standard


The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'The Web Origin Concept'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the concept of an "origin", which is often used
  as the scope of authority or privilege by user agents.  Typically,
  user agents isolate content retrieved from different origins to
  prevent malicious web site operators from interfering with the
  operation of benign web sites.  In addition to outlining the
  principles that underlie the concept of origin, this document defines
  how to determine the origin of a URI, how to serialize an origin into
  a string, and an HTTP header, named "Origin", that indicates which
  origins are associated with an HTTP request.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-origin/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-origin/


No IPR declarations have been submitted directly on this I-D.

Document write-up for draft-ietf-websec-origin, provided by
Tobias Gondrom

###

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

    Document shepherd is Tobias Gondrom.
    I have reviewed this version personally and believe it is ready.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

    The document is mature and received good review from WG and non-WG members.
    Furthermore, reviews also covered document versions before its
    adoption by the WG or even prior to the formation of the websec WG,
    namely draft-abarth-origin-09 and draft-abarth-principles-of-origin.
    The depth and breadth of the reviews is sufficient and best efforts
    have been made to involve browser vendors, though a few more reviews
    from the browser vendor companies would have been nice.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

    No.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

    No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

    WG consensus on this document seems mature and pretty robust.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

    No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

    Yes. There were a few minor warnings which have been justified.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

    Yes. All normative references are stable and OK.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

    Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

    Did run the ABNF through BAP (http://tools.ietf.org/tools/bap/) and
    validated correctly with no errors.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

      This document defines the concept of an "origin", which is often used
      as the scope of authority or privilege by user agents.  Typically,
      user agents isolate content retrieved from different origins to
      prevent malicious web site operators from interfering with the
      operation of benign web sites.  In addition to outlining the
      principles that underlie the concept of origin, this document defines
      how to determine the origin of a URI, how to serialize an origin into
      a string, and an HTTP header, named "Origin", that indicates which
      origins are associated with an HTTP request.

    Working Group Summary

      There was nothing particular worth noting about the WG process.
      No strong controversy for this document.
      The document received sufficient review from WG and non-WG members.
      Furthermore, reviews also covered document versions before their
      adoption by the WG or even prior to the formation of the websec WG,
      namely draft-abarth-origin-09 and draft-abarth-principles-of-origin

    Document Quality

      The origin concept is widely used in the web browser and application
      environment to determine trusted sources. Still it may be noteworthy
      that some current implementations of the origin concept may differ
      in whether all three elements of the origin-tuple must be identical
      to constitute identity of origin. In some current browser
      implementations e.g. scheme or port may receive less weight.

###