Re: SPARQL Security - Best Practices?

----- "Jacek Kopecky" <jacek.kopecky@sti2.at> wrote:

> From: "Jacek Kopecky" <jacek.kopecky@sti2.at>
> To: "Richard Newman" <rnewman@twinql.com>
> Cc: "Damian Steer" <pldms@mac.com>, "Brian Manley" <brian.manley@gmail.com>, "Semantic Web at W3C"
> <semantic-web@w3.org>
> Sent: Wednesday, September 3, 2008 7:44:07 AM GMT +10:00 Brisbane
> Subject: Re: SPARQL Security - Best Practices?
>
> Hi Richard, 
> if I understand it correctly, a data store is allowed to provide any
> named graphs it wishes to. Could your problem be solved with a
> special
> named graph for the merge of all the data (allowed for a user)? I
> mean
> something like this:
> 
> SELECT * 
> FROM <http://localhost/special/all>
> WHERE { 
>      ?s foo:bar ?baz ;
>         zob:zab ?bing .
> }
> 
> This would be a data-store-specific extension, but it would work with
> the standard SPARQL query lang. Actually, if the query engine
> accesses
> named graphs from a Web server, the "union of all allowed graphs"
> could
> be just another resource on that server, and the query engine would
> need
> no extensions.
> 
> Of course this does not preclude a better syntax for the same
> functionality in SPARQL 2.0. 8-)

I have been thinking about this recently, although my conclusion has so far been to make up a special graph with a known URI which provides a set of statements giving group and user level access to particular graph URI's. I don't think it is efficient to provide a graph matching algorithm with statement level privacy controls, although it would be interesting to see what the performance hit would be for integrated graph level privacy controls.

I am not, however, allowing users to directly query this dataset, so I can make up queries which always check this information and expose them as method calls (in my case web service calls). In a sense SPARQL providers started off on the entirely open agenda, as opposed to SQL databases which rarely if ever let users directly query or change arbitrary data, although the SQL specification doesn't include any mandatory privacy controls for SELECT/INSERT statements in a similar way to SPARQL.

Cheers,

Peter

Received on Tuesday, 2 September 2008 22:00:25 UTC