Re: Access Control Note

Kingsley:
It's an optional feature.  You don't have to implement it.
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:07:58 UTC