Re: [access-control] Update

Looks great!

I have a few comments:

The name "Access-Control-Origin" is IMHO confusing. First of all I would 
expect "allow" or "grant" or something like that somewhere in the syntax 
to indicate that the header is granting access. I have two counter 
proposals:

"Access-Control-Allow-Origin" ":" URL | "*"
or
"Access-Control" ":" "allow" "<" URL ">"

I would prefer the latter one as that gives us better opportunity for 
future expansions if needed. That way the future expansions can be made 
such that existing clients bail due to unrecognized syntax if we so desire.


Similarly, should we rename Access-Control-Credentials to 
Access-Control-Allow-Credentials? This feels less important to me.


Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url 
should not be a full URL, and I don't think we want to depend on HTML5 
for it either. Currently we seem to be allowing the syntax

Access-Control-Origin: http://foo.com/bar/bin/baz.html

which I think is very bad as it seems to indicate that only that page 
would be allowed to POST, which of course isn't something that we can 
enforce.

Additionally, the way the spec was written before we could create a 
conformat implementation now without having to worry about HTML5 
changing things under us.

Note that when I said during the meeting that the URI paring was the 
hardest part, I didn't mean that URI parsing was hard. I meant it in the 
sense that the spec was so easy to implement that it was even simpler 
than URI parsing.

So I strongly think we should bring back the language the spec used to 
have for parsing origins. And then the HTML5 spec can refer to the AC 
spec for origins if it so desires.

Adding a dependency on HTML5 is bad for a couple of reasons:
1. We want to be able to ship implementations now and not change their 
parsing later as that can have security implications.
2. It has been politically hard to add dependencies to unfinished specs. 
Weather we think the concerns raised have merit or not, the debate is 
likely going to cause the spec to get delayed.

Mostly I care about 1 above.


I haven't reviewed the headers/methods stuff yet. But it looks good at 
an initial overview.

/ Jonas


Anne van Kesteren wrote:
> 
> Hi,
> 
> The WebApps WG had a F2F last week in Seattle. While I'm still a bit 
> buzzed by the jet lag I managed to "finish" the work I started during 
> the weekend on updating the Access Control for Cross-Site Requests (AC) 
> specification to match resolutions and proposals made during the F2F 
> meeting. The meeting logs of the F2F are not publicly available yet, but 
> since the editor's draft is, I will summarize what I changed and 
> depending on whether you trust me or not, you can infer from that what 
> we decided upon...
> 
> The draft is available at the same place as usual:
> 
>   http://dev.w3.org/2006/waf/access-control/
> 
> Here is what I changed:
> 
>  * <?access-control?> is dropped. Might return in AC2.
> 
>  * Access-Control is now Access-Control-Origin which takes * or a URL. 
> In other words, whether or not a site grants access is simplified *a 
> lot*. Implementors who told me this was the most complex part to 
> implement can rejoice. This also makes this specification consistent 
> with Web Sockets and postMessage(), both defined in HTML5. 
> (Access-Control-Origin is not to be confused with the old 
> Access-Control-Origin, which is now Origin.)
> 
>  * Access-Control-Credentials provides an opt in mechanism for 
> credentials. Whether or not credentials are included in the request 
> depends on the "credentials flag", which is set by a hosting 
> specification. Preflight requests are always without credentials.
> 
>  * Four new headers are introduced to deal with headers and method opt 
> in. Two request headers (set by the user agent): 
> Access-Control-Request-Method and Access-Control-Request-Headers. And 
> two response headers: Access-Control-Allow-Method and 
> Access-Control-Allow-Headers. (The introduction of these headers also 
> affected the preflight result cache.)
> 
>  * The HTTP header blacklist is gone as that is something that affects 
> all hosting specifications, including same-origin requests, and 
> therefore is inappropriate in a specification intended solely for non 
> same-origin requests.
> 
>  * I've referenced HTML5 for several concepts which hopefully encourages 
> code reuse in user agents and also makes sure that we don't have to 
> change if HTML5 does.
> 
>  * An access control check is now also performed when the redirect steps 
> are applied to prevent data leakage from intranet pages.
> 
> So please review the changes made and the significant revisions to the 
> processing model. Much appreciated. If you would like to review the CVS 
> log entries you can do so here (changes since last time start at 1.178, 
> "MASSIVE CHANGE"):
> 
>   http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.html
> 
> 
> Kind regards,
> 
>

Received on Wednesday, 9 July 2008 20:23:57 UTC