Re: Access Control Note

On 8/7/14 3:11 PM, Alexandre Bertails wrote:
> 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.

Where is the triple? You don't write triples in thin-air, they are 
inscribed somewhere. Put differently, if you want to keep you home 
address or physical location private, wouldn't you place that in a 
document with its own controlled access rules?

The problem here is that the term "graph" is used too loosely, and it 
has also blurred the notion of named graphs (document identifiers).


>
> 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).

Yes, but by saying that you are basically coming back to the fundamental 
point we are making i.e., the LDPR is a document denoted by an HTTP URI. 
All named graphs aren't denoted by HTTP URIs because they don't need to 
be. In many cases they are local to the RDF (R)DBMS.

As I said to Ashok: A SQL RDBMS Table is a Database. A SQL RDBMS is a 
completely different thing that manages Databases. Every Database is a 
kind of Document. Every RDF document is basically a Database. RDF 
document can live out on a network where they are denoted by URLs or 
they can exist solely within the confines of an RDBMS (as you see with 
Oracle and optionally with Virtuoso).

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

Correct.

Triple granularity is a red herring. All you do is put the triples (RDF 
sentences or statements) in a separate document to which relevant ACLs 
are applied.
>
> 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.

In the context of LDP, we are dealing with different kinds of documents 
(note: the 200 OK response below):

curl -I http://ods-qa.openlinksw.com/~kidehen/Public/
HTTP/1.1 200 OK
Server: Virtuoso/07.10.3211 (Linux) x86_64-redhat-linux-gnu  VDB
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Date: Thu, 07 Aug 2014 17:54:41 GMT
Accept-Ranges: bytes
MS-Author-Via: DAV
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Expires: -1;
MS-Author-Via: DAV, SPARQL
Allow: 
GET,HEAD,POST,PUT,DELETE,OPTIONS,PROPFIND,PROPPATCH,COPY,MOVE,LOCK,UNLOCK,TRACE,PATCH
Accept-Patch: application/sparql-update
Accept-Post: text/turtle,text/n3,text/nt
Vary: Accept,Origin,If-Modified-Since,If-None-Match
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://ods-qa.openlinksw.com/DAV/home/kidehen/Public,meta>; 
rel="meta"
Link: <http://ods-qa.openlinksw.com/DAV/home/kidehen/Public,acl>; rel="acl"

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

We don't want red herrings in specs.

Oracle isn't really working in the manner describe by Ashok here, 
either. It is basically working at a Table (and View) level. Basically, 
as is always the case with SQL RDBMS products, there's a superficial 
illusion that is so distinct from the underlying technical reality. We 
should never burden implementers with items like this, there is zero 
upside :-)

If anyone can go beyond "Oracle appears to do it" and outline when 
separate document scoped ACLs aren't the solution, I would certainly 
enjoy the enlightenment.

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


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