- From: Thomas Roessler <tlr@w3.org>
- Date: Sat, 17 May 2008 00:10:50 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-appformats@w3.org
On 2008-05-02 22:44:45 +0000, Ian Hickson wrote: > The proposal is basically that along with the Access-Control > header, the user agent can include an Access-Include-Credentials > header. I suspect you mean that the server includes that header. > If the header is present, then, when sending the request, the > user agent includes cookies and HTTP author headers (if any > apply) as well as a Sec-Credentials-Included header to indicate > that cookies and auth tokens were included > (since the Cookie header might not be present, for instance, if > no cookies apply, and the server needs to distinguish the case of > the cookies having been potentially hidden intentionally from the > case where the cookies were simply not present). What useful information that isn't already conferred by Referrer-Root does that header transfer? > In the case of GET requests, the credentials would be omitted by > default and if the response includes the > Access-Include-Credentials then it would be sent again with > credentials. > The presence of Access-Include-Credentials would be cached along > with the policy and subject to Access-Control-Max-Age. If the policy remains part of the overall proposal, I'd propose to actually turn this into an extension of the policy language, instead of using a separate header. Strawman: Extend the syntax of the allow statement allow [ with [ auth <scheme> | cookies ] ... ] ... where <scheme> can be a string or "*". If this extension is present, then the IP address in question is allowed to cross-site requests with the given HTTP authentication scheme. If "with cookies" is present, then cookies can be sent. For the OAuth use case, I'm in fact wondering if the permission shouldn't extend to letting the code that causes the cross-site request set the authentication headers, as opposed to using "ambient" authentication tokens. If the access-control proposal should be simplified to get rid of the policy (and move toward an approach where a very simple header is used to signal authorization for some cross-site request), then the current approach sounds reasonable, with the caveat that we might wish to permit for per authorization scheme granularity. On the other hand, that, too, is additional complexity. Then again, it would appear to me that somebody who is sophisticated enough to control a policy like this one would also be able to use Referrer-Root in order to distinguish same from cross origin requests, whether or not cookies are sent. It strikes me that this discussion is best had in terms of protection goals that we want to achieve, not in terms of individual features. -- Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 16 May 2008 22:11:37 UTC