Since we appear to be in consensus about keeping the core of Pirk PIR-focused, I will capture our discussion of the 'Trust Model for Pirk' on the website (probably a new page). I will issue a PR so that folks can comment before merge.
On Mon, Jul 25, 2016 at 1:06 PM, Tim Ellison <[email protected]> wrote: > On 24/07/16 17:35, Ellison Anne Williams wrote: > > There has been a lot of good discussion lately about signing Pirk > objects, > > validating, etc in another thread. I would like for us to step back and > > consider the trust model for Pirk. > > > > Pirk is an application that runs within a user's system to provide the > > ability to (1) generate a secure query via PIR and/or (2) execute a > secure > > query via PIR. A Pirk Querier generates a Query object and a Pirk > Responder > > generates a Response object. For a user system that is running the Pirk > > application, these objects are just an output of the application. > > > > Communication between the Querier and Responder entities is necessary for > > the Querier to send the Responder a query (Query object) and for the > > Responder to return the results (Response object), but those transport > > mechanisms are external to Pirk. User systems running the Pirk > application > > can choose to communicate with each other in whatever way they would like > > to. > > > > As such, I propose that the authentication of the Query and Response > > objects remain external to Pirk. It seems that this is best left as a > part > > of the access control/authentication of users' systems that are running > the > > Pirk application and communicating with each other. > > > > This also of the same philosophy as the Responder's data access: the > > Responder can only execute a query over data to which the data owner has > > given it access. This is enforced outside of Pirk -- data access controls > > of the data owner for a data user (such as Pirk) are outside of the scope > > of the Pirk project. > > > > Thoughts? > > Yep. I think it is a good separation of concerns to leave the > authentication of messages to "the system". It's a non-trivial problem > and would add complexity to Pirk without assuring the best solution for > everyone. > > I may well play with PIR-as-a-service in due course, and fit Pirk into > the existing services to help manage these areas. > > Regards, > Tim > >
