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

[Trimming the recipients to just public-webappsec]

I support CORS advancing to CR.

Adam


On Thu, Nov 15, 2012 at 2:31 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
> 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
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>

Received on Wednesday, 21 November 2012 19:33:48 UTC