SHACL-SPARQL dataset definition

[afs]

It isn't defined in SHACL-SPARQL as to the graphs available int the dataset for the query. This leads to security risks of unauthorized access to local data.

A SHACL engine may not be executing with the same permissions as the user making the request.

SPARQL's FROM and FROM NAMED describe the dataset to be queried by giving some URIs.

There is no fixed required way to use the URIs to identify graphs. One common way is to choose named graphs from the dataset.
However, downloading graphs over HTTP is also a valid way to obtain graphs. The latter is away to leak information because the SHACL engine may not be executing with different permissions to the user making the request. SHACL engines do not typically have multi-tenant isolation.

Implicitly, the dataset for SPARQL queries is the one with the only graph being the default graph; no named graphs.
But the text does not forbid, or warn about, the dataset having other graphs accessible via GRAPH.

• FROM and FROM NAMED should be forbidden.
• The dataset for SPARQL execution should be defined as a single graph dataset.

Alternatively, the security section needs to have warnings. Delegating to the SPARQL security section is not enough because SHACL-SPARQL makes a restricted use of SPARQL.

[HolgerKnublauch]

Forbidding the GRAPH keyword (or FROM etc) sounds prohibitive, and I am sure that by now many people are used to these in SHACL (after years of not having these limitations). I am quite sure many of our customers use GRAPH, for example, to look up terms from reference data to compare it with values from the local data graph.

In the end it's the choice of the platform which graphs are available in the dataset. For example, in TopBraid we do check which named graphs are available for the current user that has triggered the SHACL engine, and access to other graphs is forbidden.

So I think adding some security warnings is more realistic. Do you think something like this would be sufficient:

Note that SPARQL directives such as GRAPH and FROM may provide access to other graphs than the active data graph in the dataset. A SHACL-SPARQL engine needs to ensure that the SPARQL engine only provides access to the same named graphs as the user who has triggered the validation.

[ajnelson-nist]

@HolgerKnublauch : Did you intend to use "needs to" in your suggested text instead of "MUST"? I can appreciate desires for either word choice here.

[HolgerKnublauch]

@ajnelson-nist yes, we can use MUST. I am just not sure if the security section is prescriptive rather than informative.

[ajnelson-nist]

I noticed RDF 1.2 Concepts and SPARQL 1.2 Query Language use the looser language; Turtle 1.2 uses a SHOULD but no MUST. I haven't searched far and wide for a Security Considerations section that uses a MUST.

Maybe instead of "needs to" vs. "MUST" we can relax this language to the same strength as used in SPARQL 1.2 Query Language, especially as this is a SPARQL-tied document?