W3C home > Mailing lists > Public > semantic-web@w3.org > September 2008

Re: SPARQL Security - Best Practices?

From: Peter Ansell <ansell.peter@gmail.com>
Date: Wed, 3 Sep 2008 09:49:12 +1000 (EST)
To: Richard Newman <rnewman@twinql.com>
Cc: Semantic Web at W3C <semantic-web@w3.org>, Damian Steer <pldms@mac.com>
Message-ID: <2913421.241220399347831.JavaMail.peter@Macintosh-2.local>

----- "Richard Newman" <rnewman@twinql.com> wrote:

> >> A couple of years ago I was working on a system that very heavily 
> >> used very complex access control. My ultimate conclusion was that 
> >> standard SPARQL was not very well suited to this kind of thing.  
> >> That's an interesting conclusion for a SPARQL implementor to draw, 
> >> but there you are :)
> >
> > Are any query languages suited to this?
> Probably not! I expect that any language sufficiently powerful would 
> either be a full-fledged programming language (cf. Prolog, which is  
> one of the query interfaces AllegroGraph supports, and which could  
> implement this sort of thing), or be too closely tied to an  
> implementation to be standardized.
> SPARQL is interesting here because features like datasets, GRAPH, etc.
> conspire to *appear* like the components one would need to build a  
> graph-based in-query access control system, when in fact they are  
> insufficient. I've had a number of people ask about it, and discussion
> of the pros and cons can become involved, particularly for people who 
> are "just users".
> Access control might be one of those things that is best left up to  
> the implementation.

Even if the aspects of access control that appear at the SELECT/CONSTRUCT etc level might be separate from the access control, it might still be valuable to have the equivalent of the SQL GRANT commands that works across implementations, with the particular implementation then deciding for each SELECT query which of the GRANT instructions apply to it based on authorisation status etc.


Received on Tuesday, 2 September 2008 23:49:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:07 UTC