ACTION-154: policy decision / enforcement points

Per ACTION-154, I'm supposed to elaborate on possible proposals for a  
"server-side" enforcement point. Much of what is in this message is
based on earlier material from Mark Nottingham, Tyler Close, and Doug  
Crockford.

(This is to get some more clarity on ISSUE-20, Client and Server
model.)

There are two basic cases that we are concerned with: GET and not
GET.  In the case of GET, the goal is to control the information
flow from the data source to a Web application running from another
origin.  In the case of other requests, the goal is to put controls
on the control flow from the web app to a server-side application
running from another origin, and on the information flow back.


For GET, we're assuming that whatever other technology is "hosting"
the "access-control" mechanism imposes a same-origin-like
restriction on the data flow, and we assume that this restriction is
part of the design assumptions that existing Web applications make.
(In fact, this restriction is a critical part of current defense
techniques against XSRF.)

For non-GET methods, we're assuming that whatever other technology
is "hosting" the "access-control" mechanism imposses a same-origin
like restriction on applications' ability to send non-GET requests
over the network.  We assume that it's worthwhile to protect
server-side applications against unexpected cross-origin requests of
this kind.

In other words, if a server doesn't know about new cross-origin
authorization mechanisms, then its environment shouldn't be changed
by whatever mechanism we propose.

Here are some design sketches:

- Discover whether the server knows of cross-site request
  authorization mechanisms, through...

  * OPTIONS, [3] or
  * a metadata file at a well-known location (P3P-like)

  If the server is found to support the mechanism, use GET and/or
  POST with Referer-Root for cross-site requests, and let the server
  figure out whether to serve data, as Mark had sketched in [1]. For
  this scheme to work properly with HTTP caches, the server must set
  an appropriate Vary header on responses to requests that can be
  cached (GET), and the cache must know how to deal with it.

  In this model, the policy is never shared with the client, and
  remains a local affair on the server.

  The model does require the server to have a local convention for
  policy authoring and an engine to interpret these policies.

  Using metadata stored in a well-known location will reduce the
  per-request overhead.

- Design cross-site requests so legacy servers won't do anything
  interesting when they are hit with them.  Whatever information is
  required by the target host is then sent along with the cross-site
  requests.
  
  Possibilities include:
  
  * use a strange content-type for POST and for responses, and don't
    include any "ambient" authentication information; JSONRequest
    takes this approach; [2]
  * use new HTTP methods (CSGET, CSPOST, ...)
  
  For the server side, same as above.
  
  In this model, no policy is shared with the client, and there is
  no overhead in terms of discovering what the server is capable of.

- Explicitly ask the server for authorization.  Tyler proposed a
  model like this in [4], using a well-known location like design
  pattern.  Using OPTIONS with a Referer-Root header is another
  possibility to the same end.

  Once more, the policy doesn't need to be shared with the client,
  and the complexity is isolated to the server side.


One point in common to almost all of these models is that there is
some rudimentary enforcement going on on the client side: The client
learns about the server's abilities or decisions, and will then
either stick to its old same-origin policy, or not.

In the "use new HTTP methods" model, that enforcement is replaced by
the client sending a distinct kind of requests.


The real distinction (and the decision that this group needs to make
and document!) between these models and the one that is in the
current spec is where the policy is *evaluated* - either, that
happens on the client (and there needs to be an agreed policy
specification, which is what this document started out being).  Or,
it happens on the server, in which case policy authoring is a purely
server-local affair.


In this context, it's worth noting (Hixie pointed, e.g., in [5]),
that it is possible to deploy the currently spec'ed technique in a
way that mostly imitates the "server-side" model: just send "allow
*" (and appropriate Vary headers), and leave the rest to the server.


I'd suggest that, as we go forward with this issue, people start
elaborating on the benefits (and downsides) of the various models,
compared to what's currently in the spec, if possible in terms of
the use cases and requirements that we have now.

Also, if you think there are additional use cases and requirements
that are missing, it's probably worth calling these out, explicitly.


1. http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0118.html
2. http://www.json.org/JSONRequest.html
3. http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D10BA65C7@G6W0269.americas.hpqcorp.net
4. http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D10C4E3B3@G6W0269.americas.hpqcorp.net
5. http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0186.html

-- 
Thomas Roessler, W3C   <tlr@w3.org>