Re: Access Control Note

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.    

    - 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 13:24:12 UTC