W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2012

Re: Indirect Graph Identification

From: James Leigh <james@3roundstones.com>
Date: Tue, 11 Sep 2012 10:31:37 -0400
Message-ID: <1347373897.2164.20.camel@james-PBL21>
To: Sandro Hawke <sandro@w3.org>
Cc: public-rdf-dawg-comments@w3.org
Hi Sandro,

See below for my response.

On Tue, 2012-09-11 at 09:51 -0400, Sandro Hawke wrote:
> Thanks for the details.
> On 09/05/2012 11:13 AM, James Leigh wrote:
> > Hi Sandro,
> >
> > If the GSP spec was changed to allow publication of URL patterns,
> > instead of the RDF Graph Store URL (as it is today), 3 Round Stones
> > would implement GSP in Callimachus and it would be included (by default)
> > with every Callimachus deployment. However, in the spec's current form
> > we would not implement the indirect graph identification portion.
> Am I right in understanding that Callimachus is not a Graph Store 
> (SPARQL database), but sits on top of one?     You're talking about the 
> possibility of Callimachus providing a GSP interface to that underlying 
> Graph Store?     What if it already implements one?

Yes, Callimachus delegates to an embedded library (Sesame) to index,
merge, and query the data store.

> > Callimachus is a Linked Data Management System and as such security is a
> > big concern. Callimachus' current authorization mechanism is based on
> > the target request uri (before the query string). In the event the
> > request is an indirect request, the authorization is based on the
> > indirect target, which is encoded in the request path (not the query
> > string).
> Perhaps this is an irrelevant detail, but maybe not.    If the 
> authorization is based on the indirect target, then why does it matter 
> how it's encoded?
> For example, let's say the underlying engine contains, in a graph named 
> "http://example.com/g1", the triple <a> <b> <c>.
> Let's say the "Graph Store" URI is http://s1.example.com/data. (Note 
> that there is currently no standard way to find this out from anywhere.  
> It might be in some Service Description, but not in any standard way.)
> So, GSP says I could get that <a> <b> <c> by doing a GET from (ignoring 
> URL encoding):
> http://s1.example.com/data?graph=http://example.com/g1
> I think you're saying Callimachus will be answering URIs starting 
> "http://s1.example.com/data", and will need to make some access control 
> decision.
> I understand you want the URL to be able to look more like:
> http://s1.example.com/data/indirect/http://example.com/g1
> So, the idea is that the access control rule can be based on 
> "http://s1.example.com/data/indirect/http://example.com/g1", but it 
> can't be based on 
> "http://s1.example.com/data?graph=http://example.com/g1" because the 
> query part is stripped off before the access control logic sees the URL?
> That would make sense, but I'm not actually sure that's what you said, 
> so please confirm that I have that right.

Yes you have it correct, but it does matter how the indirect target is
encoded. Apache works in a similar way for access control. Barring any
internal sub-processing URL rewriting, Apache's authorization is done by
directory-path pattern, which is matched to the request uri path (before
the query string).

The Graph Store Protocol's GET, HEAD, PUT, and DELETE could be enabled
using Apache using the webdav module or this third party mod_put module:

The POST handler could be enabled by writing a (simple?) RDF aware
script to merge the two graphs for apache.

However, since Apache's authorization is based on directory path,
indirect graph authorization could not be implemented without some
internal sub-processing URL rewriting.

Callimachus does not support internal sub-processing URL rewriting;
therefore Callimachus' authorization could not be used to secure
indirect graph access if the indirect graph is encoded in the query

If the spec supported publishing of indirect graph pattern URL, it would
be easier for implementations to properly secure it from the start. By
encoding the indirect graph into the query string, many implementations
may simply overlook per-graph security because it adds a significant
complicity (i.e. requires apache rewrite rules).

Received on Tuesday, 11 September 2012 14:32:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:13 UTC