[webappsec + webapps] CORS to PR plans

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