Call for Consensus: CORS to Candidate Recommendation

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<mailto: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