W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Comments on: Access Control for Cross-site Requests

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 9 Jan 2008 07:46:54 -0500
Message-Id: <9B87A865-6A29-47D4-83A2-7BF21AEB2466@nokia.com>
Cc: Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@yahoo-inc.com>, Ian Hickson <ian@hixie.ch>, "Close, Tyler J." <tyler.close@hp.com>, "public-appformats@w3.org" <public-appformats@w3.org>
To: ext Thomas Roessler <tlr@w3.org>


On Jan 8, 2008, at 6:16 PM, ext Thomas Roessler wrote:

> (Finally catching up on WG mail after the new year's break.)
> On 2008-01-03 09:54:29 +0100, Anne van Kesteren wrote:
>> On Thu, 03 Jan 2008 02:26:57 +0100, Mark Nottingham <mnot@yahoo- 
>> inc.com>
>>> Has the working group gained consensus on this requirements list and
>>> documented it?
>> As far as I can tell the Working Group has always worked with these
>> constraints in mind, but we never put them in a document.
> For the record, there was a lengthy discussion at the technical
> plenary that, I believe, there is no final agreement on the "no
> server implementation effort" requirement.

Yes it is true we never formally captured a resolution/agreement  
regarding "no sever implementation". OTOH, there has also never been  
any type of resolution/agreement that we would change our working  
assumption - that we've been using since we started with the client- 
side model documented in the VB Read Access model [VB-Note] - that  
the User Agent is a Web Browser (or Voice browser).

Regards, Art Barstow

[VB-Note] <http://www.w3.org/TR/2005/NOTE-access-control-20050613/>

> Also, among these requirements, "server ultimately controls access"
> is *very* ambiguous.
> To begin with, the distinction between a cross-site access to a
> resource and a first-party access to that resource is one that,
> ultimately, only the client can make.  Therefore, any enforcement
> mechanism *will* trust the client with a critical piece of
> information, whether that mechanism performs computation on the
> server or on the client.  One can draw different conclusions from
> this, depending on what part of the overall complexity one wants to
> keep down.
> Further, for GET, the protection goal is controlling a data flow
> that is opened up *within* the client (and is currently blocked).
> For POST and other methods, avoiding spontaneous requests seems to
> have crept in as well.  As I said before, I'm very doubtful how
> useful that is as a protection goal any more -- I think that horse
> has left the barn, quite some time ago.
> Cheers,
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>
Received on Wednesday, 9 January 2008 13:44:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC