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

Apologies for my tardy response, I've now had a chance to consider this 
thread a little more and review the relevant discussion (other POWDER WG 
members may want to chime in too of course!).

It goes without saying that there are important differences in what WAF 
Access Control and POWDER are trying to do. It's not surprising 
therefore that we're taking different approaches.

POWDER is trying to make it easy (and desirable) for content providers 
to make claims and assertions about their material. That sentence alone 
has the lawyers salivating. "You mean we're going to say in public that 
all our content is accessible? What's our liability if some of it isn't? 
Will some people try and pin other people's mistakes on us?" and so on. 
Therefore, step one to making this acceptable is making sure that even a 
lawyer can understand that it is easy to restrict any and all claims 
made to something that their client explicitly owns. So, if you're in 
the legal team at example.com, you want to be sure that claims are only 
about that domain.

 From a POWDER perspective therefore, the default position is that 
example.org matches both www.example.org and example.org. What this 
discussion has made me realise is that we need to be explicit in our 
documentation that it DOES NOT match badexample.org - i.e. a different 
domain altogether.

Like WAF, we have an exclude method as well so we can say:

<wdr:includeHosts>example.org example.com</wdr:includeHosts>
<wdr:excludeHosts>private.example.org</wdr:excludeHosts>

(which means everything on example.org and example.com except resources 
on private.example.org). The assumption being that someone describing a 
load of content would know what they wanted to leave out.

So the general approach has been, as ever, that simple things will be 
simple (we own example.com so that's the scope of this description) but 
that complex situations can also be handled (you can write a Reg Ex if 
you need to)

I wonder whether some earlier work that Mark Nottingham did might be 
adapted, see section 3.22. of URISpace [1]. There he uses both ? and * 
as different wildcard characters and posits that:

?.example.com

matches

   www.example.com
   foo.example.com

but not

   example.com
   www.foo.example.com

while

*.example.com

   will match

   foo.example.com
   www.foo.example.com

but still not

   example.com

It's that last point that, for me anyway, makes this more correct, yes, 
but also more difficult to use. Would WAF be able to specify that:

?.example.com meant 'example.com and all its subdomains'

*.example.com meant all subdomains of example.com but not example.com 
itself??

This is obviously a change from what Mark did originally but might it 
solve the problem??

As for Jonas' other point - what else could/should we share. Well, 
access control is clearly an application of what we're doing, whether 
that's in terms of licensing or my own area of child protection. I guess 
it's a question of use cases.

Our Resource Grouping mechanism has to cope with being able to cover 
everything from multiple Web sites through to individual resources; we 
also support resource grouping by property, not just URI, so there's a 
lot there. *IF* there is a sufficient use case within the WAF's purview 
to warrant such flexibility then there would be a case for an HTTP 
Header/XML PI that pointed to a POWDER-style Resource Set or maybe even 
a full Description Resource??

On a more mundane level, one of us needs to write the pattern matching 
syntax and the other one needs to point to it! As pointed to before, 
we're defining a bunch of XML data types [under development at 2] and 
can readily include one for this if desired.


Phil.

[1] http://www.w3.org/TR/urispace
[2] http://www.dicom.uninsubria.it/~andrea.perego/powder/?doc=xsd

Jonas Sicking wrote:
> I think an even more urgent question is, how much of the design is 
> POWDER and AC going to share. I see very little value in sharing just 
> the URI-matching syntax, so we need to figure out if there are more 
> things that can be shared to know if we should bother with it at all.
> 
> / Jonas
> 
> Arthur Barstow wrote:
>>
>> 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 Friday, 20 July 2007 10:13:40 UTC