Re: [webappsec + webapps] CORS to PR plans

I'd like to issue this as a formal Call for Consensus at this point.  If
you have any objections to CORS advancing to Proposed Recommendation,
please reply to public-webappsec@w3.org.  Affirmative response are also
encouraged, and silence will be taken as assent.

The proposed draft is available at:

http://webappsec-test.info/~bhill2/pub/CORS/index.html

This CfC will end and be ratified by the WebAppSec WG on Tuesday, August
13, 2013.

Thank you,

Brad Hill


On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill <hillbrad@gmail.com> wrote:

> WebAppSec and WebApps WGs,
>
>  CORS advanced to Candidate Recommendation this January, and I believe it
> is time we consider advancing it to Proposed Recommendation.  In the
> absence of an editor, I have been collecting bug reports sent to the
> public-webappsec list, and now have a proposed draft incorporating these
> fixes I would like to run by both WGs.
>
> The proposed draft can be found at:
>
> http://webappsec-test.info/~bhill2/pub/CORS/index.html
>
> A diff-marked version is available at:
>
>
> http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html
>
> (pardon some spurious diffs indicated in pre-formatted text that has not
> actually changed)
>
> A list of changes is as follows:
>
> 1. Changed "Fetch" references.  The CR document referenced the WHATWG
> Fetch spec in a number of places.  This was problematic due to the maturity
> / stability requirements of the W3C for document advancement, and I feel
> also inappropriate, as the current Fetch spec positions itself as a
> successor to CORS, not a reference in terms of which CORS is defined.  The
> proposal is to substitute these references for the "Fetching Resources"
> section of the HTML5 spec at:
>
> http://www.w3.org/TR/html5/infrastructure.html#fetching-resources
>
> I do not believe this produces substantive changes in the reading of CORS>
>
> 2. In the "Terminology" section, added a comma after "Concept" in response
> to: http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html
>
>
> 3. Per discussion to clarify the interaction of HTTP Authorization headers
> with the user credentials flag,
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 and
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0366.html,
> I have inserted the following clarification:
>
> "user credentials for the purposes of this specification means cookies,
> HTTP authentication, and client-side SSL certificates
>   <!-- begin change --> that would be sent based on the user agent's
> previous interactions with the origin. <!-- end change -->
>
> 4. In the defintion of the Access-Control-Allow-Methods header, in
> response to
> http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0046.html ,
> clarified that "The Allow header is not relevant for the purposes of the
> CORS protocol.
>
> 5. http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.htmland
>
> http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0096.htmlpoint out
>      that header and method are not defined correctly in the response
> headers for preflight requests.
>      It appears that the intent was to respond with the list provided as
> part of the preflight request,
>      rather than the potentially unbounded list the resource may actually
> support
>
>    The following clarifications were made:
>
>   (for methods) "Since the list of methods can be unbounded, simply
> returning the method indicated by
>     Access-Control-Request-Method (if supported) can be enough.
>
>   (for headers) "Since the list of headers can be unbounded, simply
> returning the headers from
>     Access-Control-Allow-Headers (if supported) can be enough.
>
> 6. In response to:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html,
> removed spurious 'than'
>
> 7. In response to:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html,
> added comma after "Concept"
>
> 8. In response to thread beginning at:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0078.html,
> added 204 as a valid code equivalent to 200 for the CORS algorithm.
>
> If these changes are acceptable to the WGs, I believe the only remaining
> steps are to prepare an implementation report and update the test suite to
> cover the 204 and 308 status codes.   I'll let us discuss these for a bit
> here before beginning a formal call for consensus.
>
> Please send comments to public-webappsec@w3.org
>
> Thank you,
>
> Brad Hill
>
>
>