Fwd: Call for Consensus: CORS to Candidate Recommendation

FYI: Some updated information about CORS which is a key component of
building client side apps with a clean modular separation from the server

---------- Forwarded message ----------
From: Hill, Brad <bhill@paypal-inc.com>
Date: 15 November 2012 23:31
Subject: Call for Consensus: CORS to Candidate Recommendation
To: "public-webappsec@w3.org" <public-webappsec@w3.org>, "WebApps WG (
public-webapps@w3.org)" <public-webapps@w3.org>
Cc: "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, "
public-web-security@w3.org" <public-web-security@w3.org>, "websec@ietf.org"
<websec@ietf.org>


 WebApps and WebAppSec WG members, (and copied security interest groups who
we invite to provide comments)****

** **

Following discussion at TPAC, I’ve resolved outstanding changes in the
security considerations section agreed to by WebAppSec as well as
differences between the W3C and WHATWG versions of CORS, and believe we are
ready to go to Candidate Recommendation.  We probably have enough
implementations to proceed directly to Proposed Recommendation, but our
test suite still needs better documentation of its coverage and some test
cases need repairs, so I believe moving to CR first, and as soon as
possible, is the right next step, while we work out those details.****

** **

I have placed a draft for review at:****

** **

http://www.w3.org/2011/webappsec/cors-draft/****

** **

And this is a Call for Consensus among the WebAppSec and WebApps WGs to
take this particular text (with necessary additions to the Status of this
Document section if approved) forward to Candidate Recommendation.****

** **

Please send comments to public-webappsec@w3.org , positive feedback is
encouraged.****

** **

This CfC will end on November 23, 2012.****

** **

Substantive changes from the last published version (both pulled from the
WHATWG version) include:****

**1.       ** updating the redirect status codes to include the newly
defined 308****

**2.       **adding the referrer source header as input to the fetch
algorithm ****

** **

Non-substantive changes include:****

** **

**1.       **Clarified text defining 5.1, Access-Control-Origin allow
header to read: the value of the Origin request header, “*”, or “null”****

**2.       **Updated “certificates differ” reason for algorithm abort to
“certificate errors”****

**3.       **Replaced “ambient authority” with “user credentials sent with
cross-origin requests”****

**4.       **Replaced a number of instances of “server” with more
consistent usage of “resource”****

**5.       **Updated language slightly about OWS in header value
definitions in HTTP/1.1 spec****

**6.       **Removed reference in security considerations to Origin header
as a credential, as it is explicitly defined as not being a credential****

**7.       **Deleted paragraph in security considerations section on
forwarding attacks as on further consideration it is not a genuine concern**
**

**8.       **Removed language about validating data in the security
considerations section comparing CORS to JSONP****

**9.       **Removed “safe and idempotent” language in security
considerations and replaced with “significance other than retrieval”****

**10.   **Changed “implicit” credentials language to “user credentials
automatically attached to the request by the user agent”****

**11.   **Updated language in security considerations on path-distinguished
application principals vs. origin-distinguished principals****

**12.   **Merged updated thanks and acknowledgements from WHATWG version****

**13.   **Removed language about multiple origins in security
considerations as that is now forbidden by the redirect steps****

**14.   **Added a non-normative “Implementation Considerations” as Section
6.4 under the Resource Processing Model with the following text:****

** **

“Resources that wish to enable themselves to be shared with multiple****

  <code>Origins</code> but do not respond uniformly with <code>"*"</code>***
*

  must in practice generate the <code>Access-Control-Allow-Origin</code>****

  header dynamically in response to every request they wish****

  to allow.  As a consequence, authors of such resources should send a****

  <code>Vary: Origin</code> HTTP header or provide other appropriate control
****

  directives to prevent caching of such responses, which may be inaccurate**
**

  if re-used across-origins.”****

** **

Thank you,****

** **

Brad Hill****

WebAppSec WG Co-Chair****