Re: Access Control Note

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.

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

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

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

Received on Thursday, 7 August 2014 14:11:30 UTC