Re: Aligning grouping of resources in POWDER and WAF Access Control.

Thanks for the update Phil.

Regarding the value of the {include,exclude}UriPatter properties, one  
of the open questions for the Read Access spec [1] is essentially  
"should *.foo.com match foo.com?". The lastest draft says "no" thus  
must use one rule for *.foo.com and another rule for foo.com.

Mozilla's Jonas Sicking summarized the issue, providing a list of  
both the Pros and Cons [2].

We are particularly interested in your feedback on this question  
(e.g. use cases, evidence of past precedence, etc.).

Art
---

[1] <http://www.w3.org/TR/2007/WD-access-control-20070618/>
[2] <http://lists.w3.org/Archives/Public/public-appformats/2007Jul/ 
0002.html>


On Jul 13, 2007, at 9:47 AM, ext Phil Archer wrote:

> Just a quick further response to this.
>
> The POWDER face to face meeting discussed the issue at our face to  
> face meeting this week (member-only minutes at [1]) and resolved*  
> "That we create a new RDF predicate that will support the kind of  
> wildcard-based URI pattern matching used by the WAF Group in their  
> Enabling Read Access document."
>
> The plan is to:
>
> 1. Rename the existing URI Pattern predicates to include/exclude  
> UriRegEx
>
> 2. Create a new RDF predicate of include/exclude UriPattern and use  
> the WAF wild-card syntax. We'll extend it a little to enable  
> control over paths as well, so that *example.com/foo* means that  
> the path must begin with /foo on any subdomain of example.com if  
> it's to be in the set.
>
> 3. We'll add this to the XSD document we're working on. This will  
> soon be converted into a working draft but for now can be seen,  
> very unofficially, at [2].
>
> Does this sound right to you? By all means ping me directly rather  
> then continue on the public lists if you prefer.
>
> Phil.
>
> [1] http://www.w3.org/2007/07/09-powder-minutes.html (member only)
> [2] http://www.dicom.uninsubria.it/~andrea.perego/powder/?doc=xsd
>
> * As most group members are European and the meeting was in  
> Washington, the number of people present wasn't high. Therefore,  
> all resolutions were taken at the f2f are subject to giving the  
> remainder of the group time to review the resolutions.
>
> Phil Archer wrote:
>> cc. POWDER public list.
>> Hi all,
>> I'm glad Art responded to this so quickly as the original mail was  
>> caught in my spam filter from which I've just retrieved it.
>> Mea culpa - I was unaware of the Enabling Read Access work. I will  
>> make sure that the POWDER WG considers it fully and that we report  
>> back (we have a face to face meeting on Monday so we can do this  
>> quickly).
>> Meanwhile, we have moved on significantly since the April blog  
>> entry referred to. Yes, we do support Perl regular expressions but  
>> we don't rely on them. Actually, we warn against their use for  
>> most scenarios, precisely because of the same reasons Art cites,  
>> preferring instead to use simple string matches against URI  
>> components. Unless something goes horribly wrong, the member only  
>> document at [1] will be a first public working draft on Monday and  
>> this is all set out there.
>> It would be easy to include a wild card pattern - indeed, there's  
>> an example of exactly that in the extension mechanism section  
>> (which refers to Google's URL pattern format which also looks  
>> similar to the one in the WAF document).
>> Clearly, there should be a common approach, or at least a fully  
>> compatible one. I notice that Opera is in both groups. Chaals,  
>> Anne - I hereby nominate you as coordinators!
>> Phil.
>> [1] http://www.w3.org/2007/powder/Group/powder-grouping/20070709.html
>> Arthur Barstow wrote:
>>> [[ ++ public-appformats - the mail list the WAF WG uses for its  
>>> technical discussions ]]
>>>
>>> Stuart - thanks for raising this issue. I have not discussed this  
>>> issue with the WAF WG nor the WAF Public Community but here is  
>>> *my* take on the syntax issue.
>>>
>>> We discussed using regular expression syntax instead of just  
>>> star. I recognize there would be some advantages to using the  
>>> richer syntax but we decided to follow the KISS principle here,  
>>> particularly given the negative side effects of incorrect syntax  
>>> (e.g. accidentally giving access to a domain that should not have  
>>> access). [I assume here the probability of incorrect syntax is  
>>> higher with regular expressions than just star but I have no real  
>>> data to back my assumption.]
>>>
>>> It also appears our decision is consistent with the decision made  
>>> in the P3P spec [1].
>>>
>>> WAF WG & Community - please see the issue the TAG raises below.
>>>
>>> Regards,
>>>
>>> Art Barstow
>>> ---
>>>
>>> [1] <http://www.w3.org/TR/P3P/#ref_file_wildcards>
>>>
>>>
>>> On Jul 6, 2007, at 10:16 AM, ext Williams, Stuart (HP Labs,  
>>> Bristol) wrote:
>>>
>>>> Art, Phil,
>>>>
>>>> In response to a request from the WAF-WG [1] to review "Enabling  
>>>> Read
>>>> Access to Web Resources" [2] the TAG is concerned to ensure that  
>>>> there
>>>> is good alignment between your WGs wrt the specification of  
>>>> resource
>>>> sets.
>>>>
>>>> We observe that [2] involves the specification of 'allow' and  
>>>> 'deny'
>>>> sets of resources (which in this case happen to be the origins of
>>>> scripted behaviours executed by user agents). There is some  
>>>> resonance
>>>> between [2] and POWDER work on grouping resource sets by  
>>>> address. We
>>>> believe that there is or should be some common interest in the
>>>> specification of such resource sets between your WGs.
>>>>
>>>> Given that web masters are the likely authors of configuration
>>>> information for both script access controls (as in [2]) and for
>>>> content-labeling (a POWDER application) and that both involve  
>>>> making
>>>> assertions about sets of resources (allow/deny assertions v  
>>>> assertions
>>>> about the nature of web content) we believe that there should be at
>>>> least some conceptual coherence and ideally some syntactic  
>>>> coherence in
>>>> the way that both POWDER and WAF-WG approach the description of  
>>>> sets of
>>>> resource that are the subject of such assertions.
>>>>
>>>> For example, consider the scenario in which the author of a  
>>>> resource
>>>> identified by http://www.sales.example.com/strategy.html wishes  
>>>> to allow
>>>> cross-domain access from any resource identified by an  
>>>> example.com URI.
>>>>
>>>> Per [2], this set is specified with a pair of 'access items' as:
>>>>
>>>>     http://*.example.com
>>>>     https://*.example.com
>>>>
>>>> Whereas using the 'PERL regexp' based approach being considered by
>>>> POWDER (option 5 at [3]), the same set is specified as:
>>>>
>>>>    ^https?://[^:/?#]+\.)*example\.com/
>>>>
>>>> We think having two similar-but-different mechanisms to achieve  
>>>> the same
>>>> goal should be avoided if at all possible.
>>>>
>>>> We would be interested to hear from you whether you think there  
>>>> is any
>>>> possibility of seeking considerably more alignment between the  
>>>> work of
>>>> your two groups, so that where their requirements overlap there  
>>>> is at
>>>> least cross-reference, and at best sharing of terminology,  
>>>> operational
>>>> semantics and perhaps even syntax.
>>>>
>>>> Best regards
>>>>
>>>> Stuart Williams
>>>> for W3C TAG
>>>> -- 
>>>> [1] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0114.html
>>>> [2] http://www.w3.org/TR/2007/WD-access-control-20070618/
>>>> [3]
>>>> http://www.w3.org/blog/powder/2007/04/27/ 
>>>> meeting_summary_26_27_april_200
>>>> 7
>>>> -- 
>>>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
>>>> Berks
>>>> RG12 1HN
>>>> Registered No: 690597 England
>>>
>>>

Received on Tuesday, 17 July 2007 16:56:34 UTC