Call for Consensus: CORS to Candidate Recommendation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Call for Consensus: CORS to Candidate Recommendation

Hill, Brad

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 [hidden email] , 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

Reply | Threaded
Open this post in threaded view
|

Re: Call for Consensus: CORS to Candidate Recommendation

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

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



Reply | Threaded
Open this post in threaded view
|

Re: Call for Consensus: CORS to Candidate Recommendation

Glenn Adams-2
Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document.

On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow <[hidden email]> wrote:
On 11/15/12 5:31 PM, ext Hill, Brad wrote:

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.


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




Reply | Threaded
Open this post in threaded view
|

Re: Call for Consensus: CORS to Candidate Recommendation

Ms2ger
I object to making such a change.

On 11/16/2012 02:32 PM, Glenn Adams wrote:

> Before going to CR, I believe the [HTML] entry in the references section
> needs to be changed to reference an appropriate W3C specification. A
> present, it reference a non-W3C document.
>
> On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow <[hidden email]>wrote:
>
>> On 11/15/12 5:31 PM, ext Hill, Brad wrote:
>>
>>>
>>> I have placed a draft for review at:
>>>
>>> http://www.w3.org/2011/**webappsec/cors-draft/<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.
>>>
>>>
>> 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<http://www.w3.org/TR/2012/CR-websockets-20120920/#crec>
>>>
>>
>> -Thanks, AB
>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Call for Consensus: CORS to Candidate Recommendation

Glenn Adams-2
Cox will file an FO (as a W3C member) if it is not fixed.

On Fri, Nov 16, 2012 at 6:51 AM, Ms2ger <[hidden email]> wrote:
I object to making such a change.


On 11/16/2012 02:32 PM, Glenn Adams wrote:
Before going to CR, I believe the [HTML] entry in the references section
needs to be changed to reference an appropriate W3C specification. A
present, it reference a non-W3C document.

On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow <[hidden email]>wrote:

On 11/15/12 5:31 PM, ext Hill, Brad wrote:


I have placed a draft for review at:

http://www.w3.org/2011/**webappsec/cors-draft/<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.


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<http://www.w3.org/TR/2012/CR-websockets-20120920/#crec>


-Thanks, AB








Reply | Threaded
Open this post in threaded view
|

[admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]

Arthur Barstow
In reply to this post by Ms2ger
The W3C's process documents (e.g. #PubRules) define the policies for
publications and this issue will be addressed if/when the CR is actually
published.

WebApps is simply a user of the publication policy. If you want to
discuss W3C processes such as PubRules, please use some other list - and
not any of WebApps' lists - such as public-w3cprocess #ProcCG.

-Thanks, AB

#PubRules <http://www.w3.org/2005/07/pubrules?uimode=filter>
#ProcCG <http://lists.w3.org/Archives/Public/public-w3process/>

On 11/16/12 8:51 AM, ext Ms2ger wrote:
> I object to making such a change.
>
> On 11/16/2012 02:32 PM, Glenn Adams wrote:
>> Before going to CR, I believe the [HTML] entry in the references section
>> needs to be changed to reference an appropriate W3C specification. A
>> present, it reference a non-W3C document.


Reply | Threaded
Open this post in threaded view
|

Re: [admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]

Glenn Adams-2
Unless I've missed it, I don't believe the #PubRules provides guidelines on what documents are referenced by a spec and whether the reference is normative or non-normative. If I'm wrong, please point out the policy or pubrules text that addresses this issue.

Just to be clear, I don't object to including a non-normative reference to the WHATWG variant specification; however, if it is to be a normative reference, I'd like to insist it be the official W3C document that is referenced.

On Fri, Nov 16, 2012 at 7:14 AM, Arthur Barstow <[hidden email]> wrote:
The W3C's process documents (e.g. #PubRules) define the policies for publications and this issue will be addressed if/when the CR is actually published.

WebApps is simply a user of the publication policy. If you want to discuss W3C processes such as PubRules, please use some other list - and not any of WebApps' lists - such as public-w3cprocess #ProcCG.

-Thanks, AB

#PubRules <http://www.w3.org/2005/07/pubrules?uimode=filter>
#ProcCG <http://lists.w3.org/Archives/Public/public-w3process/>

On 11/16/12 8:51 AM, ext Ms2ger wrote:
I object to making such a change.

On 11/16/2012 02:32 PM, Glenn Adams wrote:
Before going to CR, I believe the [HTML] entry in the references section
needs to be changed to reference an appropriate W3C specification. A
present, it reference a non-W3C document.