The technical content of the spec looks fine as far as I can tell, but
it's a little obscured by editorial matters.
I can see why something that looks just like current CORS specs is
convenient to the WebApps WG reviewers,
but for a wider audience, consider an introduction such as:
--------
Introduction
Web applications increasingly seek to combine resources from multiple
administrative domains. Consider the case of content from
customer.example.org sending a request (via a script, a form, etc.) to a
resource specified by service.example.com. For the protection of
service.example.com, user agents enforce a /Same Origin Policy (SOP)/
that prohibit this message exchange. To enable the message exchange,
service.example.com would need some means to opt-out of this protection.
The main goals of this specification are:
1. Provide a means for resources to allow cross-origin messaging.
2. Provide a means for clients to engage in origin independent
messaging without the danger of Cross-Site-Request-Forgery (CSRF)
and similar attacks.
We introduce an HTTP response header that allows a resource to opt-out
of SOP protection for a given HTTP response in order to meet the first
of these goals.
To understand the second goal, consider an attack case, in which
service.example.com wants the request delivered to a resource that
customer.example.org has permission to use but service.example.com does
not. ...
--------
Also, in the abstract, I hate "This document...". How about "Uniform
messaging is a mechanism..." in place of "This document defines a
mechanism..."?
Re the use of "SOP" to stand for "Same Origin Policy," I have a hard
time not reading it as "Standard Operating Procedure." I don't have a
suggested fix.
Re "the familiar CSRF attack," I'd appreciate a citation at 1st use of
the term. Likewise "HTTP response splitting vulnerabilities."
Also, re "virtue of being the same subset supported by the HTML form
element"; that's not derived from HTML specs, is it? That's just
well-known lore about how HTML is implemented? A citation would be
nifty, though I can imagine there isn't a good one.
The anthropomorphism in "content sending a request" and "resources
should add a header" rubs me the wrong way. I suppose I don't mind
thinking of resources as agents, but maybe "content specifies a request"?
I don't grok "If the permissions needed for a POST are provided in
response to a GET, ..." . Help?
Also.. "When placing permissions ..." confused me;
s/permissions/credentials/?
typo? "Ensure not the reveal" should be "... to reveal"?
for reference:
Uniform Messaging, Level One
Editor's Draft 21 November 2009
Editors:
Tyler Close (Google)
Mark Miller (Google)
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0931/draft.html
--
Dan, writing from a machine not yet outfitted with a .sig
