W3C home > Mailing lists > Public > public-lod@w3.org > June 2010

Re: [foaf-protocols] Yet Another FOAF+SSL ACL Test: ACLs Baton Passing

From: mike amundsen <mamund@yahoo.com>
Date: Sat, 19 Jun 2010 12:20:20 -0400
Message-ID: <AANLkTimAi-vLFULYjF6xlGNIY2gZrjuKcC1OxHMtrj6x@mail.gmail.com>
To: nathan@webr3.org
Cc: Kingsley Idehen <kidehen@openlinksw.com>, foaf-protocols <foaf-protocols@lists.foaf-project.org>, Linked Data community <public-lod@w3.org>
I started this thread to as a way to get us thinking about this
fundamental shortcoming of the WAC pattern as described in the initial
paper [1] and the Wiki [2].

The pattern where agents can deref the resource in order to discover
the ACL of that resource is viable for cases where the agent already
has access to the resource. However, cases where the agent needs to
gain access to the resource itself needs another pattern; one which
I've not seen proposed/documented anywhere.

[1] http://dig.csail.mit.edu/2009/Papers/ISWC/rdf-access-control/paper.pdf
[2] http://esw.w3.org/WebAccessControl


On Sat, Jun 19, 2010 at 11:56, Nathan <nathan@webr3.org> wrote:
> mike amundsen wrote:
>> <snip from Kingsley>
>> (the resource URL is discoverable via Link: response headers):
>> </snip>
>> <snip from Nathan>
>>> try:
>>> https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt,acl
>> </snip>
>> Hopefully, the irony is not lost here.
>> Kingsley's message listed a URI of a resource; the LInk header of
>> which pointed to the URI of the ACL resource.
>> IOW, I was given rights to the ACL resource, but not the resource
>> controlled by that ACL resource.
>> Thus, "Discovering the ACL resource via the Link Header" *was not
>> possible*.
>> So I must ask, Nathan, how did you know the URI of the ACL resource?
>> What have I missed?
> nothing, the demo should have let you have access to both the resource and
> the ACL, why you didn't I'm not sure - defer to Kinglsey on that one ;)
> Best,
> Nathan
Received on Saturday, 19 June 2010 16:20:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:06 UTC