Using Semantic Web Data: Proof Lalana Kagal Decentralized Information Group MIT CSAIL Eric Prud'hommeaux Engineer World Wide Web Consortium

Importance of Proofs Proofs for policy decisions allow users to understand how the results were obtained Increase trust in the policy reasoning and enforcement process Used by policy administrators to confirm the correctness of the policy and to check that the result is as expected In the case of failed queries, they can be used to figure out what additional information is required for success

Problem with Proofs Proofs or explanations generated by reasoning engines are usually in the form of proof-trees Proofs or explanations generated by reasoning engines are usually in the form of proof-trees Image courtesy http://clip.dia.fi.upm.es/~logalg/slides/

Explanations Proof trees not easy to understand by end users Too much information in proof trees Need to extract relevant information from proof trees and present to end users in easy to understand manner Require explanations

AIR Policy Language rule-based policy language for usage and access control integrated explanations for policy decisions through dependency tracking more efficient and expressive reasoning through the use of goal direction mainly forward chaining backward chaining is used to limit search space grounded in Semantic Web technologies for greater interoperability, reusability, and extensibility

AIR Tools AIR Reasoner accepts data + policy and produces reasoning result of running policy over data Justification UI accepts reasoning result, extracts explanation, and displays it

Installing AIR Tools Explanation/Justification User Interface Download Firefox extension from http://dig.csail.mit.edu/2007/tab/ Install into Firefox browser Restart Firefox

Executing AIR Tools Install Tabulator extension with justification UI Remote Call reasoner on web server with remote log and policy Invoke reasoner and view justification

Testing AIR Justification UI Start Firefox Open http://dig.csail.mit.edu/TAMI/2007/s0/mit-policy.n3

If installed correctly Tabulator loads the representation of the policy as

Testing AIR Justification UI Open http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/TAMI/2007/s0/log .n3&rulesFile=http://dig.csail.mit.edu/TAMI/2007/s0/mit-policy.n3 This calls the AIR reasoner on mr-burns.w3.org and returns the reasoning result

Testing AIR Justification UI

Testing AIR Justification UI To see the result in the AIR Justification UI Press in the Tabulator to turn the RDF view OFF Press in the Tabulator to turn the Justification view ON

Testing AIR Justification UI

AIR specifications Each AIR policy consists of one or more rules policy = { rule } A rule is made up of a pattern that when matched caused the associated action to be fired rule = { pattern, action } An action can either be an assertion, which is a fact that is added to the knowledge base or a nested rule action = { assertion | rule } :MyFirstPolicy a air:Policy; air:rule [ air:pattern { ... }; air:assertion { ... }; air:rule [ ... ]

AIR specifications An AIR policy or rule also contains . air:variable used to declare variables that can be used inside patterns the scope of variable is the container in which it is declared. If the variable is bound before a rule is invoked, it is passed as a constant air:description: list of variables and strings that are put together to provide the NL description :MySecondPolicy a air:Policy; air:variable :VAR1; air:rule [ air:variable :VAR2; air:pattern { ... }; air:assertion { ... }; air:description (:VAR1, “ is a variable that is declared in :MySecondPolicy and ”, :VAR2, “ is a variable that is declared in this rule”); air:rule [ ... ] .

Scenario: Decentralized Access Control The DIG group has several online resources including pictures, papers, presentations, and proposals that are only accessible to members of the group and to people that members trust. The group has a webpage that lists its members using N3. The page identifies members by their Friend Of A Friend (FOAF) pages. Authentication in this scenario is via OpenID. DIG members provide their OpenID URI (usually the same as their work homepages) in their FOAF pages. Open http://dig.csail.mit.edu/2008/Talks/0518-SemTech-eplk/code/data.n3 for this data about the DIG group Policy: Only group members are allowed to access group resources or people who are trusted by group members For simplicity, the data that we check our demo policies against also include a test request for a DIG resource

Scenario: Decentralized Access Control For simplicity, the data that we check our demo policies against also include a test request for a DIG resource :Req1 a air:Request; foaf:openid <http://auth.mit.edu/oshani>; air:resource <http://dig.csail.mit.edu/proposals/nsf.tex/>.

Developing First Policy POLICY: If a request is for a DIG resource, it is compatible with the DIG Policy :DIGPolicy a air:Policy; air:variable :REQ, :RESOURCE. rdfs:label "DIG Policy"; air:rule :DAP_1. :DAP_1 a air:BeliefRule; rdfs:label "DIG Rule #1"; air:pattern { :REQ a air:Request; air:resource :RESOURCE. :DIG data:owns :RESOURCE. }; air:description (:REQ " is a request made by a requester with openid, " :REQUESTER ", for DIG resource " :RESOURCE); air:assert { :REQ air:compliant-with :DIGPolicy }.

Visualising First Policy Open policy at http://dig.csail.mit.edu/2008/Talks/0518-SemTech-eplk/code/first.n3

Executing First Policy To execute AIR policy: http://<air-reasoner>?logFile=<data>&rulesFile=<policy> <air-reasoner>=http://mr-burns.w3.org/cgi-bin/server_cgi.py Executing First policy http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/first.n3

Executing First Policy

Executing First Policy Press to browse through the explanation The yellow bar provides the NL description of the rule The blue bar provides the actual premises that were used to come up with the conclusion Premises are rule patterns with variables substituted

Developing Second Policy Modify first policy to check other attributes of the Request Check if the openid URI of the requester has been provided

Executing Second Policy Execute this policy and see if it works http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/second.n3

Developing Third Policy Open the data file and see if there are any other attributes passed along with the Request and check those in the policy as well Open http://dig.csail.mit.edu/2008/Talks/0518-SemTech-eplk/code/data.n3

Developing Third Policy There are no other attributes in Request, so there is no need of a third policy

Developing Fourth Policy Add another rule to the policy; check if the requester is a member of the DIG group :DAP_2 a air:BeliefRule; rdfs:label "DIG Rule #2"; air:pattern { :DIG foaf:member :MEMBERLIST. :MEMBER air:in :MEMBERLIST. :MEMBER a foaf:Person; foaf:openid :REQUESTER. }; air:description ("The requester with openid, " :REQUESTER ", is a DIG member"); air:assert { :REQ air:compliant-with :DIGPolicy }.

Visualising Fourth Policy Open fourth policy http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/fourth.n3

Executing Fourth Policy Open http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/fourth.n3 Explore the explanation using WHY and START OVER buttons

More AIR Specifications So far, we've used air:Policy, air:variable, air:BeliefRule, air:pattern, air:description, air:assert More air tags air:alt An alternative is a rule that becomes active if the pattern of the containing rule fails. This alt property is used to assert closure over some set of facts. Consider the following example. If the pattern of :RuleB matches, then the assertion fires, otherwise the alternative, :RuleC becomes active. :RuleB a air:Belief-rule; air:variable :MEMBER; air:pattern { :MEMBER air:in :MEMBERLIST. }; air:assert { :MEMBER foaf:member :DIG }; air:alt [ air:rule :RuleC ]. :RuleC a air:Belief-rule; ...

Using alt tag Add a new rule to the policy to create fifth.n3 The rule is fired if the requester is not a DIG group member The rule checks if the requester is known to any of the DIG members This rule should be an alternative to rule, DAP_2 fifth.n3: http://dig.csail.mit.edu/2008/Talks/0518-SemTech-eplk/code/fifth.n3

Executing the fifth policy In order to test this we need a new request from someone who is known to a DIG member Yosi, with openid <http://auth.mit.edu/syosi>, is not a DIG member but is known by one :Req2 a air:Request; foaf:openid <http://auth.mit.edu/syosi>; air:resource <http://dig.csail.mit.edu/proposals/nsf.tex/>. Open http://dig.csail.mit.edu/2008/Talks/0518-SemTech-eplk/code/data2.n3 Why does this Request satisfy the new policy ?

Executing the fifth policy Open http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data2.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/fifth.n3 Explore the explanation using WHY and START OVER buttons

Executing the fifth policy

How are explanations generated ? specific set of premises from which any conclusion/policy decision was derived is an effective explanation for the conclusion these premises are called the set of dependencies and dependency tracking is the process of maintaining dependency sets for derived conclusions

Dependency Tracking We use Truth Maintenance System (TMS) for tracking dependencies of conclusions keeps track of the logical structure of a derivation has ability to assume and retract hypothetical premises http://en.wikipedia.org/wiki/Truth_maintenance_systems Explanations are automatically generated by extracting and presenting relevant information from dependencies

Overriding Automatic Justification Using dependency tracking, we are able to generate explanations for every conclusion reached by the reasoner However, sometimes we need to override these explanations When the explanation is too lengthy, we might want to reduce the number of steps When the explanation exposes too much information about the policy, we might want to protect our policy

AIR tags for explanation We use the following tags to modify the dependency structure and provide customized explanations air:assertion property of rules This property is composed of two components, air:statement, which is the set of triples being asserted, and air:justification, which is the explicit justification that needs to be associated with the statement. The Justification class consists of two properties air:rule-id and air:antecedent. The rule-id can be set to the name of the rule that the assertion is to be attributed to and the antecedent is a list of matched graphs that would act as the premises. It is possible to obtain the matched graphs of rules by using the matched-graph property of Rules with a variable.

Sixth policy Modify fourth policy to provide a different explanation for DAP_2 :SomeOtherRule a air:BeliefRule; air:variable :REQ, :G1; air:matched-graph :G1; air:pattern { :REQ a air:Request; }; air:rule :DAP-1. :DAP-2 a air:BeliefRule; rdfs:label "DIG Rule #2"; air:pattern { }; air:description ("The request is valid"); air:assertion [ air:statement { :REQ air:compliant-with :DIGPolicy }; air:justification [ air:rule-id :SomeOtherRule; air:antecedent :G1 ] ].

Sixth policy

Execute sixth policy Open http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/sixth.n3 Explore the explanation using WHY and START OVER buttons

Execute sixth policy

Lawyer View We also have a different view of our justification UI, a lawyer view This presents the explanation in a non graphical format, in a style more suited for lawyers To activate this, execute any policy, and press th e button

Lawyer View of Fourth Policy Open http://mr-burns.w3.org/cgi- bin/server_cgi.py?logFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/data.n3&rulesFile=http://dig.csail.mit.edu/2008/Talks/0518-SemTech- eplk/code/fourth.n3 To activate lawyer view, and press the button

Lawyer View of Fourth Policy

How AIR fits into our accountability framework Accountability allows violators of applicable privacy policies to be identified and held accountable Privacy usage restrictions and resource access control policies are specified in AIR user's actions within the framework are captured and annotated transaction logs are maintained Policy compliance over transaction logs can be checked using the AIR reasoner

AIR Contributions automated explanations for policy decisions customizable explanations, if required more efficient and expressive reasoning extraction of relevant explanation for policy decision presenting explanations in Justification UI

More Information Air specifications: http://dig.csail.mit.edu/TAMI/2007/AIR/ Paper on AIR, Integrated Policy Explanations via Dependency Tracking, http://dig.csail.mit.edu/2008/Papers/IEEE%20Policy/air- overview.pdf TAMI/E2ESA: http://dig.csail.mit.edu/TAMI/ How to use the Justification UI : http://dig.csail.mit.edu/TAMI/2008/JustificationUI/howto.html