- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Tue, 19 Jun 2012 13:53:15 -0700
- 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 UTC