Using Semantic Web Data: Proof

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

2. 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

3. 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/

4. 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

5. 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

6. 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

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

8. 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

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

10. If installed correctly • Tabulator loads the representation of the policy as

11. 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

12. Testing AIR Justification UI

13. 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

14. Testing AIR Justification UI

15. 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 [ ... ]

16. 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 [ ... ] .

17. 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

18. 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/>.

19. 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 }.

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

21. 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 policyhttp://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

22. Executing First Policy

23. 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

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

25. 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

26. 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

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

28. 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 }.

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

30. 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

31. 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; ...

32. 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

33. 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 ?

34. 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

35. Executing the fifth policy

36. 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

37. 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

38. 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

39. 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.

40. 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 ] ].

41. Sixth policy

42. 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

43. Execute sixth policy

44. 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

45. 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.n3To activate lawyer view, and press the button

46. Lawyer View of Fourth Policy

47. 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

48. 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

49. 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