Re: ACTION-154: policy decision / enforcement points

On 2008-01-25 15:19:57 +0100, Thomas Roessler wrote:

> - 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)

I forgot to mention:

   * a metadata file at a location that is discovered through
     OPTIONS, and/or through an HTTP response header.

>  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>

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

Received on Tuesday, 29 January 2008 10:20:26 UTC