Re: Access Control Note

On 8/7/14 2:07 PM, Ashok Malhotra wrote:
> Kingsley:
> It's an optional feature.  You don't have to implement it.

I understand that. My real concern is that its a red herring. You don't 
want those in specs.


Kingsley
> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this