Re: Access Control Note

On August 7, 2014 9:31:32 AM EDT, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:
>I don't know what you mean by anti-pattern.

"An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive"  - Wikipedia

>We have customers using it.

With LDP?   How does it interact with caching?   How does it affect metadata like last-modified and the etag?    Do those change even though the bytes are same when triples I can't see change?  

How does it interact with social features like endorsing?   Can people endorse a source that turns out to say something else that they were not allowed to see?

How about query routing metadata?   Void?    Are those things made wrong, or do they show different results to different users?

What about linked data?   Is my data broken because I liked you your site and you silently show different stuff to different users?

Humans manage to deal with websites which show different content to different users because we're very smart.   My understanding is it opens a huge can of worms and makes things way more complicated down to road to do that with RDF sources.

    - Sandro

>All the best, Ashok
>
>On 8/7/2014 9:24 AM, Sandro Hawke 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.
>>
>>      - 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 17:50:39 UTC