- From: Alexandre Bertails <alexandre@bertails.org>
- Date: Thu, 7 Aug 2014 10:11:02 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: ashok malhotra <ashok.malhotra@oracle.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On Thu, Aug 7, 2014 at 9:24 AM, Sandro Hawke <sandro@w3.org> wrote: > On August 7, 2014 9:07:15 AM EDT, Ashok Malhotra <ashok.malhotra@oracle.com> wrote: >>Kingsley: >>It's an optional feature. You don't have to implement it. > > The point is it's an anti-pattern. Until someone comes up with a compelling use case, sub-LDPR access control shouldn't even be an option. Here is a access control rule operating at the triple granularity: "only friends of mine can know my physical address, others shouldn't even know that such a triple exist". That is definitely a valid use-case. Now, a valid *technical* solution could recommend applications to split their LDPRs so that they can have different ACLs (that's how I would do it). And the Access Control mechanism would not give triple granularity control as a result. But this is up to the next WG to decide how they want to address this requirement because this spec is not about providing a solution. Finally, ACLs at the triple level in a more tradition RDF store (eg. quad store, graph store, SPARQL engine, etc.) would not be a valid use-case as such: the context here is LDP, nothing else. The fact that Oracle supports that in their database may be a motivation for Ashok, but I don't see a problem in the spec in that regard. Alexandre > > - Sandro > >>All the best, Ashok >> >>On 8/7/2014 6:48 AM, Kingsley Idehen wrote: >>> On 8/6/14 9:34 PM, Ashok Malhotra wrote: >>>> Some quad stores provide access to individual triples. >>> >>> Yes, Virtuoso does that. >>> >>>> I know that Oracle allows that and our product folks would like to >>>> provide access control at the triple level. >>> >>> Virtuoso supports ACLs scoped to named graph IRIs. For all the >>reasons already outlined in prior posts from Sandro, Henry, and I. >>> >>>> Thus, I am reluctant to remove this requirement. >>> >>> Sorry, but the requirement reflects misunderstanding of the role of >>named graphs in relation to triples. >>> >>> Look at it this way, from an RDBMS that supports RDF perspective: >>> >>> 1. A named graph denotes an internal document identifier -- remember, >>a Table is a document in an RDBMS (because a database != rdbms system; >>they are distinct things) >>> >>> 2. You protect documents not specific sentences and paragraphs in >>documents -- redaction isn't the same thing as ACLs, in the case of >>ACLs you are (like in the real world) controlling access to documents >>in a folder, cabinet, cube, building etc.. all of which relate directly >>to the subject at hand here. >>> >>> >>> Even if you tried to implement triple scoped ACLs, it would die of >>inflexibility and horrific performance. Scalability is not even a >>discussion. >>> >>> Here's an example of a Named Graph ACL template, represented in >>Turtle Notation: >>> >>> ## Protected (Private) Resource Authorization denoted by the IRI >><{ACL-IRI}> ; >>> ## created by the Identity Principal denoted by the IRI >><{Rule-Creator-WEBID}> ; >>> ## granting Read/Write privileges to the Named Graph denoted by the >>IRI <{Target-Named-GRAPH-IRI}> ; >>> ## to identity principals denoted by the following IRIs list >><{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}>, >>> >>> PREFIX oplacl: <http://www.openlinksw.com/ontology/acl#> >>> PREFIX acl: <http://www.w3.org/ns/auth/acl#> >>> PREFIX foaf: <http://xmlns.com/foaf/0.1/> >>> >>> <{ACL-IRI}> >>> a acl:Authorization ; >>> rdfs:label "ACL based Data Access Policy Example" ; >>> rdfs:comment """An ACL based Data Access Policy used to control >>access to a specific named graph, >>> denoted by a named graph IRI that functions >>as the object of an ac:accessTo relation. >>> This particular policy grants Read and Write >>privileges to >>> Identity Principals denoted by the list of >>URIs functioning as the object of the acl:agent relation. """ ; >>> foaf:maker <{Rule-Creator-WEBID}> ; >>> oplacl:hasAccessMode oplacl:Read, oplacl:Write ; >>> acl:accessTo <{Target-Named-GRAPH-IRI}> ; >>> acl:agent <{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}> ; >>> oplacl:hasScope oplacl:PrivateGraphs ; >>> oplacl:hasRealm oplacl:DefaultRealm . >>> >>> >>> >>> Kingsley >>>> All the best, Ashok >>>> >>>> On 8/6/2014 2:11 PM, Sandro Hawke wrote: >>>>> On August 5, 2014 5:52:45 AM EDT, Kingsley Idehen >><kidehen@openlinksw.com> wrote: >>>>>> On 8/5/14 10:02 AM, henry.story@bblfish.net wrote: >>>>>>> On 4 Aug 2014, at 23:32, Ashok >>Malhotra<ashok.malhotra@oracle.com> >>>>>> wrote: >>>>>>>>> Henry: >>>>>>>>> We decided to remove access control for attributes (parts of >>>>>> triples) >>>>>>>>> We did not discuss removing access control for triples. >>>>>>>>> We can discuss this if you wish. >>>>>>> I don't see how you can do access control on parts of triples at >>all. >>>>>>> >>>>>>> The argument as I understand it is that one can only give access >>or >>>>>> not >>>>>>> at the HTTP layer to a resource. What state of the resource you >>show >>>>>>> is another topic: call it filtering. That could be an orthogonal >>>>>> spec. >>>>>>> It is best to keep things simple and distinct to arrive at a >>>>>> consensus. >>>>>>> Henry >>>>>>> >>>>>> +1 >>>>> +1 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> > > >
Received on Thursday, 7 August 2014 14:11:30 UTC