Re: [webappsec + webapps] CORS to PR plans

On Wed, Aug 7, 2013 at 8:54 AM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Mon, Aug 5, 2013 at 5:48 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> 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.
>>>
>>
> I would suggest using "is sufficient" or "is adequate" rather than "can be
> enough". "Can be" implies that it may be or may not be. Need to be more
> definite.
>
>
>>
>>> 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.
>>>
>>
> Would this be considered a substantive technical change? Or correction to
> an editorial oversight? I see below that 204 (and 308) tests need to be
> added, which makes it sound a little like a technical change.
>
>
>>
>>> 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.
>>>
>>
> What is the status on resolving the open bugs at [1]?
>
> [1]
> https://www.w3.org/Bugs/Public/buglist.cgi?list_id=22771&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=CORS&product=WebAppsSec
>
>
>>
>>> Please send comments to public-webappsec@w3.org
>>>
>>> Thank you,
>>>
>>> Brad Hill
>>>
>>>
>>>
>>
>