- From: mike amundsen <mamund@yahoo.com>
- Date: Mon, 21 Jun 2010 13:28:10 -0400
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: nathan@webr3.org, foaf-protocols <foaf-protocols@lists.foaf-project.org>, Linked Data community <public-lod@w3.org>
yep. i can deref the primary resource URI i see the Link Header for ACLs i can deref the ACL URI, too. I've not tested editing the ACL URI yet. 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 > > > > >
Received on Monday, 21 June 2010 17:28:45 UTC