Subject: [websec] Call for Consensus: CORS to Candidate Recommendation

From: "Hill, Brad" <[email-masked]>
Date: Thu, 15 Nov 2012 22:31:24 +0000

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 [email-masked]<mailto:[email-masked]> , 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

---

From: Arthur Barstow <[email-masked]>
Date: Fri, 16 Nov 2012 08:17:44 -0500

On 11/15/12 5:31 PM, ext Hill, Brad wrote:
> 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.
>

I support this CfC although I am wondering about the CR exit criteria.

Do you expect to re-use the CSP1.0 criteria:

[[
The entrance criteria for this document to enter the Proposed 
Recommendation stage is to have a minimum of two independent and 
interoperable user agents that implementation all the features of this 
specification, which will be determined by passing the user agent tests 
defined in the test suite developed by the Working Group.
]]

My preference is what WebApps has used in other CRs because I think it 
is clearer that a single implementation is not required to pass every 
test but that at least two implementations must pass every test. F.ex.:

    <http://www.w3.org/TR/2012/CR-websockets-20120920/#crec>

-Thanks, AB