W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2012

Re: comments on Cross-Origin Resource Sharing (CORS) of 3-Apr-2012 (was: hey hey)

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 19 Jun 2012 13:53:15 -0700
Message-ID: <4FE0E6BB.3040300@KingsMountain.com>
To: W3C Web App Security WG <public-webappsec@w3.org>
Anne replied:
 >
 > On Wed, Jun 6, 2012 at 1:08 AM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
 >
 >> Brad's incorporation of my comments into CORS sec considerations is largely
 >> fine by me. I've attached a further-redlined version (both .docx and .pdf)
 >> of the redlined .pdf he had sent to the list with some modest mods.
 >
 > 1) Doing this as PDF/Word documents makes it extremely painful to integrate.

apologies, AFAIK Brad did that in order to make use of Word's "track changes" 
functionality.

We could use some guidance on W3C spec-editing practices such as communicating 
markups.

I can re-send the revised security considerations section in html if that'll help.

I would obtain the present doc source here..

   http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.src.html

..yes?


 > 2) I'm not sure the new text is actually better. E.g. it contains the
 > phrase "This specification defines how to authorize an instance of an
 > application from a foreign origin, executing in the user agent, to
 > access the representation of the resource in an HTTP response." Origin
 > is a user-agent centric concept. Turning it around seems unwise and is
 > inconsistent with the rest of the specification and any other
 > specification on the subject.
 >
 > It's also not clear to me we need to reiterate what
 > http://tools.ietf.org/html/rfc6454 already explains.

that doesn't match my reading of RFC6454. "origin" (nee "web origin") is about 
designating the source of "content", which isn't strictly "user-agent centric.

 From RFC6454's introduction <https://tools.ietf.org/html/rfc6454#section-1>..

    Traditionally, user agents have divided content according to its
    "origin".  More specifically, user agents allow content retrieved
    from one origin to interact freely with other content retrieved from
    that origin, but user agents restrict how that content can interact
    with content from another origin.

..and from section "3.2. Origin" 
<https://tools.ietf.org/html/rfc6454#section-3.2>..

    In principle, user agents could treat every URI as a separate
    protection domain and require explicit consent for content retrieved
    from one URI to interact with another URI.  Unfortunately, this
    design is cumbersome for developers because web applications often
    consist of a number of resources acting in concert.

    Instead, user agents group URIs together into protection domains
    called "origins".  Roughly speaking, two URIs are part of the same
    origin (i.e., represent the same principal) if they have the same
    scheme, host, and port.

(note the use of the term "web application").

=JeffH
Received on Tuesday, 19 June 2012 20:53:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 20:53:42 GMT