• At DIG:
• DIG Home
• TAMI project
• AIR Policy Language

Overview

We propose to extend our AIR (Accountability in RDF) policy language to capture the semantics of query-based privacy policies. The AIR policy language is aimed at meeting policy compliance requirements of open, decentralized information infrastructures such as the World Wide Web and large enterprise systems. It is able to provide detailed explanations for policy compliance and non-compliance by using dependency tracking. The explanation feature will be particularly useful in this program because it will allow database owners to check the correctness of their policy and allow users to trust that their policy is being enforced correctly. We will also modify the AIR reasoner to understand the properties of these queries and incorporate compliance checking for both individual and combinations of queries.

In stage 1, we will support policy compliance over SPARQL queries by extending SPASQL to express a subset of SPARQL as RDF graphs so that AIR policies can be written over different components of queries.

In stage 2, We allow policies to be written at a higher level and be less dependent on the query and database structure.

In stage 3, we will support SQL queries either converting SQL to RDF directly or via SPARQL.

Policy Assurance Tools

Justification User Interface

Download Tabulator Firefox extension to view demos below

SPARQL to N3 Translator

Policy Generator

Policy Execution Service

SPARQL Endpoint

Use Cases

Use Case 0: Understanding Structure of SPARQL policies

• Example query 1 (Not compliant. Refers to SSN in WHERE clause, and outputs SSN data.)
• Example query 2 (Not compliant. Refers to SSN in WHERE clause.)
• Example query 3 (Not compliant. Refers to SSN in WHERE clause, does a FILTER on the SSN, and outputs SSN data.)
• Example query 4 (Compliant. Does not contain any references to SSN.)
• Example query 5 (Not compliant. Refers to SSN in the OPTIONAL section of the WHERE clause, and outputs SSN data if it is available.)
• Example query 6 (Compliant. Does not contain any references to SSN.)
• Example query 7 (Not compliant. Refers to SSN in the OPTIONAL section of the WHERE clause, even though it does not output SSN data.)

Use Case 1: Types of Policies

• ~A: Restriction (not). May not view something of type:A, at all.
  • i.e. the running example, "cannot query a user's SSN."
  • Example 1, Example 2, Example 3, Example 4
• A (+) B: Exclusion (xor). May view type:A or type:B, but never both.
  • i.e. "cannot query a user's bank account number and SSN."
  • Example 5, Example 6, Example 7, Example 8
  • Example 8a: Sample of incorporating query history.
• A <-> B: Inclusion (and). May only view type:A if type:B is also present.
  • i.e. "can only get the photo of users over 18."
  • Example 9, Example 10, Example 11, Example 12
• A -> ~B: Blocking (ordered xor). Viewing type:A prevents viewing type:B.
  • i.e. "cannot query for driver's license number after having queried SSN."
  • Example 13, Example 14, Example 15, Example 16

Use Case 2: Using External Semantic Web Information

• Scenario: The user may not retrieve attribute X when filtering based on condition Y.
  • Example: The user may not retrieve Home Phone when filtering based on Birth Date > 1991.
  • Implementation: This is equivalent to "the user may not view field X unless also filtering to exclude minors." This may lead to a new primitive, "requirement", meaning that a user must do some Y in order to view some X.
  • See the sample policy, and three examples: Example 1 (incompliant), Example 2 (incompliant), and Example 3 (compliant - fixes Example 1).
• Scenario: The user may ONLY retrieve attributes X, Y, and Z from a database. This is a kind of "default deny" policy.
  • Example: The user may only access the first and last name of users in a particular database.
  • Implementation: This is equivalent to blocking, as defined above, using the log:notIncludes operator instead of log:includes.
  • See the sample policy, and two examples: Example 1 (compliant), and Example 2 (incompliant).
• Scenario: The user may not retrieve attribute X or any of its subclasses.
  • Example: The user may not retrieve addresses of people living in New England.
  • Implementation: The policy first checks whether the 'where' clause contains predicates relating to state, zipcode, city, or address. If it does, then it looks to see if the object is a subclass of New England.
  • See the sample policy , and two examples: Example 1 (compliant) , and Example 2 (incompliant) .
  • Here is this policy in its generic form. Note that this one uses the new translation of SPARQL into n3. Example 1 should be non-compliant, and Example 2 should be compliant.
• Scenario: The user may only retrieve boolean values from a table.
  • (Silly) Example: The user can only query if there exist people over eighteen, but not retrieve names or ages.
  • Here is this policy in its generic form. Note that this one uses the new translation of SPARQL into n3. Example 1 should be non-compliant, and Example 2 should be compliant.

Use Case 3: Query History

Use Case 4: Controlling Source/Graphs

We should also consider policies which control what tables a user has access to. The following generic policies will do just that. Note that these all use the new translation of SPARQL.

• From Prohibited Policy
  • A policy that prohibits the user from using the FROM or FROM NAMED statement with a generic set of URIs "http://URIgeneric1.html", "http://URIgeneric2.html", "http://URIgeneric3.html".
  • Here is the policy. Query 1 should be non-compliant, whereas Query 2 should be compliant.
• From Required Policy
  • Requires the user to specify the location of the database at "http://URIgeneric1.html", "http://UIRgeneric2.html", or "http://URIgeneric3.html".
  • Here is the policy. Query 1 should be compliant, whereas Query 2 should be non-compliant.
• Default Deny From Policy
  • Allows the user to only specify information retrieval from a set of pre-determined graphs.
  • Here is the policy. Query 1 should be compliant, whereas Query 2 should be non-compliant.
• Two Sources Policy
  • A generic policy that specifies the following: if a user searches in a table "http://URIgeneric1.html", then the user may not search in "http://URIgeneric2.html".
  • Here is the policy. Query 1 should be non-compliant, whereas Query 2 should be compliant.

Use Case 5: Meta-Policies and More Control

Using the AIR policy language, it is also possible to use some more sophisticated policy control. For example, we can place several policies on one document. This allows us to build several base policies which may be used frequently, and match them as we see fit. For example, we can have a policy checking for which variables are retrieved, and another checking from where they are retrieved, in concurrence.

Another useful possibility is to nest policies, thus having some act only if the query is compliant with another policy. In the following example, the RtPolicy, which is simply a Superclass policy in disguise (see above), is checked first. If it is non-compliant, then the second policy, Then_Policy, will take into affect. Here, Then_Policy is rather simple, and simply returns that the query is compliant. However, we could check for more conditions by adding rules, therefore making it a non-trivial policy.

The policy in its raw form, and an example query.

References

• IARPA Test April 2010: Exam, SQL-RDF generation, test suite, parsed SQL queries, manually generated AIR policies, FOAF profiles, results
• A Policy-Awareness Architecture for Preserving Privacy Based on Semantic Policy Tools, Lalana Kagal and Joe Pato, IEEE Security & Privacy Sp Issue on Privacy Preserving Sharing of Sensitive Information (PPSSI), 2010
• Preventing Active Timing Attacks in Low-Latency Anonymous Communication, Joan Feigenbaum, Aaron Johnson, and Paul Syverson, Proceedings of the 2010 Privacy Enhancing Technologies Symposium
• Yale Technical Report on Usability of Browser-Based Tools for Web-Search Privacy, Felipe Saint-Jean and Joan Feigenbaum
• Yale Technical Report on Approximate Privacy: PARs for Set Problems, Joan Feigenbaum, Aaron D. Jaggard, and Michael Schapira, January 2010
• Query-Based Database Policy Assurance Using Semantic Web Technologies, by Jose Soltren, August 2009. Master's thesis.
• Presentation slides for Lincoln Lab and DIG, April 2009. Prepared by Jose Soltren.
• Presentation at IARPA APP Kickoff Meeting, March 2008
• SPARQL Query Language
• Overview paper describing language and prototype implementation: Lalana Kagal, Chris Hanson, and Daniel Weitzner, Integrated Policy Explanations via Dependency Tracking, IEEE Policy 2008
• AIR examples and online demos
• AIR ontology
• Draft of AIR Language Formalization
• TAMI project