End to End Semantic Accountability (E2ESA) Deliverable: Scenario 9 

Authors:
Li Ding
Lalana Kagal
K. Krasnow Waterman 
Abstract:
A public report on a scenario for testing E2ESA infrastructure.
Latest version:
http://dig.csail.mit.edu/TAMI/2007/s9/deliverable
STATUS:
Working Draft, last modified on 2007-11-08.

1. Overview

1.1 Goals

Scenario 9 is a test-bed for policy language and policy checking mechanisms in our accountability infrastructure with the following goals:
Below are several important notions used throughout this report:
Part of our motivation is to ensure that people who suffer adverse consequences (e.g., ranging from the loss of an apartment or job to the loss of life or liberty) as a result of such violations of their privacy will have an aid in their path to redress. For this reason, each of our scenario's variation illustrates a real-world harm that might result from law and policy violations and how this technology might help to identify the system or human failure which caused it.

1.2 Requirements

  1. The scenario should be "real" such that:
    1. Events similar to those in the transaction logs can be found in real world electronic audit systems
    2. Policy-checking process simulates real world lawyers' activities
    3. Policy-checking results can be consumed by judges, government managers, and lawyers
    4. There should be a reasonable number of events for scalability test.
  2. The scenario should demo complex points of failure such that 
    1. it is not possible to avoid the failure by telling a single person or group, "Don't do x again.". 
    2. In other word,  the violation cannot be caught simply by stopping a single transfer or group of transfers. For example, even though actor A is entitled to have access to data D, it is not permissible to use D for purpose P.
  3. The policy checking process may need OWL DL inference over transaction logs, policies, or both to ensure completeness of policy checking. For example, knowing the diagnose of Mycobacterium tuberculosis may not directly tell whether it will  lead to "imminent risk of harm to the individual or others". If we use additional OWL inference on an disease ontology to infer that Mycobacterium tuberculosis is a kind of contagious diseases,  we can easily see the relation because the "imminent risk" is part of contagious diseases' definition.

1.3 Storyboard  

Thread 1: Medicare transactions over an index case  

Thread 2: Business transactions that denies a service request

Thread 3: Legal investigation on adverse consequence

1.4 Resources

2. Scenario Design

2.1 Notations and templates

Variations (of scenario 9)

A variation of scenario 9 can be used as a competence test for the expressiveness of policy language or the functionality of policy reasoner.  A variation consists of three parts

Events

Laws and Policies

2.2 Transaction Variations -- types of point of failure

Variation 1. The most simple case: policy violation caused by direct use of information

In this variation,  we show how one event (the event in red color) in the transaction log directly violated one policy.

  • transaction logs 
    • thread 1
      • transaction 10
        • To conduct TB investigation, CDC queried Xphone for data about Alfred Newman
        • Xphone transferred Alfred Newman's record to CDC
      • transaction 11
        • To conduct TB investigation, CDC queried Xphone for data about all people whose numbers Alfred Newman had called, including Bob Same
        • Xphone transferred Bob Same's record to CDC
        • Xphone recorded the event of sending CDC personal records and the reason
    • thread 2
      • transaction 15
        • event1: "Bob" requested "Betty" (Xphone service rep) approve "install home phone for Bob"
        • event2: "Betty" queries "Xphone database" to "find Bob Same's records"
        • event3:  "Xphone database" informs "Betty" with the records about "Bob Same"
        • event4: "Betty" refused "Bob" in reply to event1 with reason "Bob was identified by TB investigation as possible carrier".
  • laws and policies
    • MA Disability Discrimination(MADD):  no one (in MA) should use one's health information to deny the person's benefits
      • Exception for risk of imminent harm
  • expected results
    • Violation of MADD if there is no risk of imminent harm, Betty should not use Bob's health information to deny Bob's request for Xphone benefit
    • Test if policy engine support OWL inference on rdfs:subPropertyOf
  • test data and policy
  • test result
    • AIR can represent MADD and Policy engine can detect the violation
two events in transaction 15 (variation 1)
Figure 1.  violation of Massachusetts Disability Discrimination law in one event (event4) from transaction 15 (variation 1)


Variation 2. Complicated case, test policy representation (indirect use of information)

In this variation, we show a rule violated by a chain of events. Betty denies the customer a benefit using customer's records obtained by someone else about his health information. Indeed, she is not supposed to use any data derived from the health information.

four events in transaction 15 (variation 2)
Figure 2. violation of Massachusetts Disability Discrimination law in three events (event5-7) from transaction 15 (variation 2)

Variation 3,  DPA computation.  data purpose inheritance


Variation 4,  DPA computation. Policy representation (policy preemption and purpose introduction)

When disclosing information, Xphone will attach appropriate purpose to it as the result of enforcing their privacy policies.



possible future variation:  Complicated case, test policy representation, rule preemption

in this variation, we show an event is allowed after applying preempted rules

possible future variation: Complicated case, test connection to OWL, using existing OWL inference feature

in this variation, we show that event log can be enriched by including the ontology referenced by transaction log using OWL DL inference.

users may defined a hierarchy of classes to classify diseases, e.g. The class disease-TB may have an super class "contagious-disease" (see a relevant ontology and  NCBI page) which can cause imminent harm to other people. With such class hierarchy,  Xphone can justify their disclosure of customer's information to CDC.  

e.g. use owl:Restriction and DL class subsumption inference.  When specifying the rule, owl Restriction is preferred because we cannot previous assume we can fully enumerate class members. 

possible future variation: Complicated case, testing system scalability, the full transaction log,

possible future variation: Complicated case, test transaction log? information leakage

prevent CDC disclose TB infection information, or prevent company collect such information?

possible future variation: Complicated case, test access control, accessing daisy girl scout database

how a RDF database can be equipped with privacy policy checking upon data access request.


3. Publication Plan 

4. Conclusions

We have generated a scenario to investigate expressiveness of policy language and expected policy checking mechanisms.

References

Change Log


Last updated on Nov 11, 2007. Maintained by Li Ding.