search

solid / web-access-control-spec

Web Access Control (WAC)
https://solid.github.io/web-access-control-spec/
MIT License
121 stars 25 forks source link

Data that may be used in query answering but not projected #58

Open kjetilk opened 5 years ago

kjetilk commented 5 years ago

If we decide to have SPARQL on the server side, an interesting problem emerges:

The simplest way to evaluate a query is to only evaluate it over data that the user has been authorized to read. However, with server-side SPARQL, there is a difference between reading and exposing data, i.e., the query engine could evaluate a query over data that the user is not allowed to read, and the data would not be projected to the user. I.e. the SPARQL engine reads data just to evaluate a query, but the client doesn't see those data.

There are obviously risks to this, the client might be able to piece together the data that was used with the knowledge that it gained from queries that it was allowed to run. However, I think this calls for a new mode.

RubenVerborgh commented 5 years ago

there is a difference between reading and exposing data

Can you give concrete examples where this would be useful?

There exists literature on such situations, and how (to prevent that) differential queries can reconstruct (parts of) the original data.

kjetilk commented 5 years ago

there is a difference between reading and exposing data

Can you give concrete examples where this would be useful?

No, it was more like "hey, this would actually be easy to implement, so lets make sure it is on the radar if need arises" :-)

There exists literature on such situations, and how (to prevent that) differential queries can reconstruct (parts of) the original data.

Yeah, I haven't read it though. So the "easy" above refers to the situation where you don't worry about the reconstruction problem.