Securing Data Access with Templated Queries

[AdamSobieski]

Introduction

How can interoperating systems, e.g., intelligent agents in multi-agent systems, each having their own databases or knowledge graphs, provide access control with respect to their resources? Could verifying and validating each structured query, in these regards, be simplified?

The idea presented here is to use templates to transform structured queries into objects more resembling remote procedure calls so that verifying and validating these, for well-known query types, could be performed more efficiently.

Interestingly, in this approach, the objects resembling remote procedure calls also describe a process with which to obtain their corresponding structured queries.

Text-based templates could be processed, alongside bindings for their parameters, into structured queries. These templates could utilize a notation like {{name}} or {{name type}} to indicate those positions in them to be replaced by those arguments bound to their template parameters.

Examples

XML

Let us consider a templated SPARQL query, a resource at https://resource.org/form-1.template, which might resemble:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?title
WHERE
{
  ?book dc:title ?title .
  ?book dc:creator ?author .
  ?author foaf:name "{{author}}" .
}

Next, the following markup:

<template input="text/template" output="text/sparql" src="https://resource.org/form-1.template">
  <param name="author">Bob Smith</param>
</template>

indicates to process the templated query, replacing {{author}} with Bob Smith so that the resultant SPARQL query would be:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?title
WHERE
{
  ?book dc:title ?title .
  ?book dc:creator ?author .
  ?author foaf:name "Bob Smith" .
}

Here is an example with a template that is to be processed into SQL:

<template input="text/template" output="text/sql" src="https://resource.org/form-2.template">
  <param name="param1">value1</param>
  <param name="param2">value2</param>
</template>

Here is an example which provides alternatives between two templating formats available. That is, there could be more than one text-based templating format.

<template>
  <source input="text/template1" output="text/sparql" src="https://resource.org/form-3-a.template1">
    <param name="param1">value1</param>
    <param name="param2">value2</param>
  </source>
  <source input="text/template2" output="text/sparql" src="https://resource.org/form-3-b.template2">
    <param name="param1">value1</param>
    <param name="param2">value2</param>
   </source>
</template>

Here is an example showing how a cryptographic hash could be used to further describe a template resource.

<template input="text/template" output="text/sparql" integrity="md5..." src="https://resource.org/form-4.template">
  <param name="param1">value1</param>
  <param name="param2">value2</param>
</template>

JSON

Here is what the templating model could resemble as expressed in JSON:

{
  "template": "https://resource.org/form-5.template",
  "input": "text/template",
  "output": "text/sparql",
  "arguments": {
    "param1": "value1",
    "param2": "value2"
  }
}

Discussion

The indicated techniques map the processing, the verification and validation, of structured queries into the processing of objects more resembling remote procedure calls.

With caching, recipients of structured queries could efficiently retrieve recognized templates from their caches.

In some cases, software functions could be developed for well-known URLs.

In other cases, runtime code generation could be of use. Generated or emitted functions – these functions perhaps involving compiled queries or optimized query plans – could be indexed by the well-known URLs and subsequently invoked with the provided arguments, after these were validated.

The indicated techniques could contribute to making both transmission and computation more efficient when securing or providing access control systems for databases and knowledge graphs, in particular when the expected structured queries are to be from a well-known, extensible set of possibilities.

Conclusion

Thank you for any feedback on these ideas.