Re: Indirect Graph Identification

On 09/11/2012 10:31 AM, James Leigh wrote:
> 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:
> http://perso.ec-lyon.fr/lyonel.vincent/apache/mod_put.html
>
> 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
> string.
>
> 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).

Okay, I understand now, thanks.    That's where I thought you were 
going, but I wasn't sure, and hadn't thought about how Apache fits into 
this.

So, we managed to talk about this at today's meeting, and the group 
concluded that this kind of functionality is out of scope for the 
current group, but is welcome in the future.   As I understand it, the 
group doesn't feel it has enough experience with the combination of 
Service Description and Graph Store Protocol to be ready to tie them 
together.   Instead, the group wants to leave the door open for 
experimentation and future work.

We'll modify the text about Indirect Identification to make it clear 
that this is only one possible way to do it, and others might be 
standardized in the future.  Then others are welcome to experiment, 
discuss it on public-sparql-dev, possible make a W3C Member Submission. 
(Personally, I think a good blog post and vocabulary could be all that's 
needed to make a de facto standard here.)

While I understand this isn't the ideal outcome, I hope you understand 
there are limits to how much we can standardize in this incarnation of 
the group.   (We have until the end of the year to get eight specs to 
Rec.)    Thanks again for laying this out so clearly, and please let us 
know whether, under the circumstances, you are satisfied with this response.

    -- Sandro

Received on Tuesday, 11 September 2012 15:32:56 UTC