Brief review of Enabling Read Access for Web Resources

Hello everyone, 
 
In preparation for next week's teleconference, here is a brief review of
the draft "Enabling Read Access for Web Resources" [2] from the WAF WG.
 
The specification describes a mechanism by which documents can permit
access to themselves from other than the domain of the URI which
references them. This provides a way to control cross domain access.
 
The specification refers to this as opening a constrained hole in the
browser's 'default sandbox'. Currently, browsers simply prevent attempts
to dereference resources from domains other than that of the page being
viewed. Such operations might be initiated by script running in the page,
for example. This specification attempts to relieve the restrictions in a
controlled way. 
 
The definition of sets of URIs from which a representation of a particular
resource may be accessed is defined in terms of a grammar. This allows
wild cards to be used in various ways in place of various parts of a URI.
Using the grammar it is possible to define sets of related URIs from which
access to the resource (actually to a particular representation of the
resource) is allowed. 
 
Since the access control is embedded in the representation, different
representations of the same resource could easily specify different access
control rules. The author does not seem to cover this particular
eventuality.
 
Since the default behaviour of browsers is not to allow any cross domain
access, this approach seems to be safe. Documents need to be authored
explicitly to allow cross domain access. Only newly authored documents or
servers with the appropriate configurations will be able to support this
new feature.
 
Aside from numerous typographic issues with the draft, there are a few
areas where the TAG might want to comment.
 
First, the use of terminology is rather loose. In particular, there is a
lack of clarity between 'resource' and 'representation'. (Maybe I'm just
hypersensitive to this after the recent Range-14 discussions!) The lack of
distinction might have contributed to the lack of a discussion about
different representations of the same resource having different access
control rules.
 
Second, the mechanisms cited for transferring this information seem to
exclude the common form of HTML. A mechanism based on a new HTTP header is
described, as is one based on an XML processing instruction. I remember
being told that servers rarely honour the http-equiv meta element in
*HTML* family languages, which could make controlling the headers
difficult. I'm prepared to be told that this is not, in fact, an issue.
 
Third, the bulk of the detail in the specification is in terms of
algorithms that must be implemented in browsers. This is unhelpful in that
there is no proper description of the rules being employed. It almost
looks as though the specification is being reverse engineered from an
implementation. It also seems unusual for a W3C specification to demand a
particular implementation.
 
Fourth, this specification seems to overlap rather with the work of the
POWDER working group [2]. The access control mechanism in [1] relies on
making assertions about sets of URIs. The assertions relate to whether or
not access is allowed.
 
The POWDER work is concerned with general mechanisms for making assertions
about sets of URIs. I would cite a working draft of a POWDER specification
here, were that not currently member-private.
 
Generally, the requirements of the access control mechanism seem to be a
subset of those of POWDER. The approach taken by the two specifications
is, however, quite different. POWDER uses semantic web techniques to make
the assertions.

Best wishes
Rhys
 <blocked::http://lists.w3.org/Archives/Member/tag/2007Jun/0063.html>  
[1]  <blocked::http://www.w3.org/TR/2007/WD-access-control-20070618/>
http://www.w3.org/TR/2007/WD-access-control-20070618/
[2]  <blocked::http://www.w3.org/2007/powder/>
http://www.w3.org/2007/powder/