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

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 22 Jun 2010 00:22:42 -0700
Message-ID: <4C2064C2.2010304@openlinksw.com>
To: mike amundsen <mamund@yahoo.com>
CC: foaf-protocols <foaf-protocols@lists.foaf-project.org>, Linked Data community <public-lod@w3.org>
mike amundsen wrote:
> yep. i can deref the primary resource URI
> i see the Link Header for ACLs
> i can deref the ACL URI, too.
>   

Great!
> I've not tested editing the ACL URI yet.
>   

Okay.

Kingsley
> mca
> http://amundsen.com/blog/
> http://mamund.com/foaf.rdf#me
>
>
>
>
> On Mon, Jun 21, 2010 at 12:52, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>   
>> mike amundsen wrote:
>>     
>>> well, I now have access to the primary URI (the mappings document),
>>> but my attempts to deref the ACL URI supplied in the link header are
>>> failing. I am prompted for my cert, supply it, and then see the HTTP
>>> auth dialog.
>>>
>>>
>>>       
>> Please try again.
>>
>> A fix has been applied to the test instance re. access to the ACL.
>>
>> Kingsley
>>     
>>> BTW - according to the details outlined in the paper[1] (pg. 6 table
>>> 1) once I get "Write" access to the ACL resource, I can delete that
>>> ACL document, correct?
>>>
>>> [1] http://dig.csail.mit.edu/2009/Papers/ISWC/rdf-access-control/paper.pdf
>>>
>>> mca
>>> http://amundsen.com/blog/
>>> http://mamund.com/foaf.rdf#me
>>>
>>>
>>>
>>>
>>> On Sat, Jun 19, 2010 at 12:20, mike amundsen <mamund@yahoo.com> wrote:
>>>
>>>       
>>>> 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
>>>>
>>>> mca
>>>> http://amundsen.com/blog/
>>>> http://mamund.com/foaf.rdf#me
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>           
>>>
>>>       
>> --
>>
>> Regards,
>>
>> Kingsley Idehen       President & CEO OpenLink Software     Web:
>> http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>     
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
Received on Tuesday, 22 June 2010 07:23:14 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:27 UTC