Proposal: Access-Controlled SPARQL Query over a Solid Pod

[jeswr]

Problem. There's no standard way to query a pod's RDF server-side — clients must fetch whole resources and filter locally.

Proposal. A read-only HTTP endpoint answering SPARQL over a pod, returning only the triples the authenticated agent may Read. A new read interface layered on the pod's existing authorization (WAC/ACP) — authentication-mechanism-agnostic, like the core Solid Protocol; not a new authorization model or wire protocol. Invariant: a query never reveals a triple the agent couldn't read directly.

Draft. https://github.com/jeswr/solid-specs/tree/main/specs/access-controlled-query
Live preview. https://jeswr.github.io/solid-specs/specs/access-controlled-query/

Status. Unofficial editor's draft, offered for the group's consideration and discussion.

[uvdsl]

Thank you, @jeswr, for proposing this to the group!
I'll need some time to read into it more carefully but I do have an immediate question:

What is the relation of this proposal's resource-graph-mapping approach (Section 5) to e.g. the SPARQL 1.2 Graph Store Protocol? Would it be possible to build on-top of the Graph Store Protocol here?

[jeswr]

Great question. The principal is that this is just an authenticated SPARQL endpoint for querying data across Solid resources.

The mapping defines how a server should internally map what is available via the LDP API of the SPARQL Protocol; to the SPARQL endpoint.

As I believe we discussed in the CG call. It would be possible to make this a separate document that defines how to semantically interpret the resources made available via the LDP API as an RDF Dataset.

[uvdsl]

Yes, hence the question! 🙂 If that mapping is basically already defined by the graph store protocol, then you could simply re-use that mapping, invert it, and put the access control on top of it?

[jeswr]

then you could simply re-use that mapping, invert it, and put the access control on top of it?

Right - I am with you now. That indeed is quite a sensible idea. The thing we still need to prescribe is how to present resources which themselves contain Named Graphs (e.g. VCs which have the proof in a named graph). There are a few ways this can be done:

• Use rdf:reifies with "traditional" RDF 1.1 reification
• Use quoted triples to describe the Named Graph within a resource and its contents
• Make that available as a separate named graph (e.g. as urn:subgraph:RESOURCE_URI:GRAPH_URI) on the SPARQL endpoint

I will implement your feedback and report back.

[tophcodes]

Hi @jeswr. I'm currently working on a quadstore-backed Solid pod using some manas components and oxigraph. My goal was to have swappable quadstore backends and expose a read-only SPARQL endpoint. During my implementation of the write semantics, I also realized that there's multiple ways to represent named graphs in resources.

Unrelatedly, and before I found this proposal, I ended up at your third option which I am currently implementing. I'm planning to mint a separate graph per (resource, inner graph name) pair, with the original name kept as data in a server-owned graph. Some observations from that, for whatever they're worth here.

In the draft you name the cost of that route as "name-rewriting or provenance table". That cost seems to depend on how the pod stores things: I'm coming at this from the other side. Solid resources stored in a quadstore, rather than a query view layered over documents. There the write path needs that table anyway: a PUT replacing a resource has to know which inner graphs the previous representation created, otherwise they linger and the next write to the same name inherits them. So the mapping exists regardless of whether anything queries it.

That's all storage-side, and as far as I can tell the two are separable: I can keep inner graphs at rest and still flatten what a query endpoint exposes, so nothing in the draft forces the storage shape either way. Mostly noting that option 3 works out in practice so far and might not even incur meaningful costs, in case the fidelity mode ever needs a route that doesn't depend on RDF 1.2.

Minor, on your example IRI: urn:subgraph:RESOURCE_URI:GRAPH_URI can't be split back apart reliably, since : can occur in both parts (https://pod.example/a + urn:x:b and https://pod.example/a:urn + x:b give the same string). Percent-encoding the parts, length-prefixing them, or hashing the pair all avoid it. I decided to hash instead.

[elf-pavlik]

@tophcodes I believe @jeswr has a Rust implementation of this proposal in https://github.com/sparq-org/sparq

[uvdsl]

@jeswr, might I ask you to update the #sotd to reflect that this specification is (not yet) published by the W3C Solid Community Group but (for now "just") a personal draft proposed to the CG? 🙂 Thank you!

[TallTed]

I think making SPARQL a key ingredient of a Solid Pod server will shrink the number of likely Pod server implementations over time.

I'm not strictly against the idea — Virtuoso was an early implementation of a Solid Pod server, and I believe it is still conformant, though I haven't paid close attention since COVID and other issues consumed too much of my brain since 2020 — but Virtuoso only provides SPARQL services over Pods it serves because it provides SPARQL services across very nearly all data it serves and/or virtualizes and/or replicates.

But at the least, I think SPARQL should be a OPTIONAL service provided by a Pod server.