1. Modeling  Conversation  Policies using Permissions  and  Obligations Lalana Kagal and Tim Finin University of Maryland, Baltimore County AAMAS Workshop on Agent Communication, NYC, 19 July 2004 http://ebiquity.umbc.edu/v2.1/event/html/id/42/  http://creativecommons.org/licenses/by-nc-sa/2.0/ Lalana Kagal and Tim Finin University of Maryland, Baltimore County AAMAS Workshop on Agent Communication, NYC, 19 July 2004 http://ebiquity.umbc.edu/v2.1/event/html/id/42/  http://creativecommons.org/licenses/by-nc-sa/2.0/

2. 2 of 30 Outline  Key Idea  Our Approach  Introduction  Framework  Example  Policy Specification Language  Policy Enforcement  Related Work  Summary

3. 3 of 30 Key Idea  Key idea: It’s policies all the way down  We think of agent protocols (e.g., FIPA contract- net) as policies  Security and trust policies limit with whom agents can communicate  Privacy policies constrain what agents can reveal  Declarative contracts say what an agent can and must do  … Rules for cooperative behavior …  … Individual preferences …  Maybe the same mechanisms can or should be used to reason over and integrate all of these?

4. 4 of 30 Our Approach  Policies are rules of optimal behavior  Optimal? Policies are normative and describe what should be done in an ideal world.  Policies provide high-level control of entities in the environment  Entities? These can be programs, services, agents, devices and people  Using policies reduces the need to modify code in order to change systems’ behavior  So? We assume modifying policies will be easier than modifying Java.

5. 5 of 30 Our Approach  Declarative policies guide the behavior of entities in open, distributed environments  Positive and negative authorizations & obligations  Focused on domain actions, including communicative acts  Policies are based on attributes of the action (and its actor and target) and the general context – not just on their identity of the actor  Policies are applied at different levels  From OS and networking to middleware to applications

6. 6 of 30 Our Approach  Conversation specifications are described in terms of simple permissions and obligations based on the sequence of messages received and sent  Conversation policies are permissions and obligations restricting how the specifications are used. They are defined over the message content and overall context.  Other policies like management, social, privacy etc. are defined at a higher level of abstraction and restrict general behavior of the agent  Whenever they deal with communication, higher level policies are translated into conversation policies using the syntax and semantics of the communication language  Agents use a policy engine to help decide what communicative act to perform next

7. 7 of 30 Specifications  Agents communicate via communicative acts (CAs) to fulfill collaborative goals  A conversation is a sequence of CAs between agents towards satisfying a particular goal  Conversation specifications define the order in which CAs can occur in a conversation  They define restrictions on the CAs that can/must be used based on the sequence of messages received thus far  They are defined as simple +/- permissions and obligations

8. 8 of 30 Policies  Conversation policies define additional restrictions on communication based on attributes of the CAs (sender, content, etc.), the state of the agent, and other context  They are also defined as +/- permissions and obligations  They provide flexible and high level control over agent communication without affecting the communication modules

9. 9 of 30 Specs Vs Policies  Specs define all possibilities,  Ideally, higher policies narrow what’s allowed and broaden what’s required.  But there’s room for conflict…  We assume that conversation policy is always of higher priority than the specs Specs Policies Specs (i) Restriction Policies (i) Intersection Specs

10. 10 of 30 Framework  Communicative act  Performative(Sender, Receiver, Proposition)  Domain action  Action(Actor, Target, PreCondition, Effect)  Deontic concepts  Deontic(Actor, Action, Constraint, {Sanction})  Conflict resolution  Priority and modality precedence  Conversational history logging  received(Msg)  sent(Msg)

11. 11 of 30 Example Specification: FIPA QUERY-REF  CAs used : QUERY-REF, REFUSE, AGREE, FAILURE, INFORM  Sequence of messages  An agent sends a QUERY-REF message to another agent.  The latter can reply either with a REFUSE or an AGREE stating its intent to either provide an answer or refuse to answer.  Once an agent has sent an AGREE, it is obliged to send an INFORM providing the information required or to send a FAILURE.

12. 12 of 30 FIPA QUERY-REF  Every agent has the permission to perform a QUERY-REF performative  permission(X, query-ref(X, Y, Proposition),_)  On receiving a QUERY-REF, the recipient is obliged to either REFUSE the query or AGREE to provide the answer  obligation(Y, refuse(Y, X, Proposition), received(query- ref(X,Y, Proposition)),_, _)  obligation(Y, agree(Y, X, Proposition), received(query- ref(X,Y, Proposition)),_,_)

13. 13 of 30 FIPA QUERY-REF  Once an agent has accepted a QUERY-REF, it is obliged to answer to it either with a FAILURE or with an INFORM and the agent is obligated to the recipient of the agree message  obligation(Y, failure(Y, X, Proposition), sent(agree(Y, X, Proposition)), X, _)  obligation(Y, inform(Y, X, Proposition), sent(agree(Y, X, Proposition)), X, _)

14. 14 of 30 Policies  Policies add restrictions on what performative can/must be used  Conversation policies are defined in terms of communication language and domain specific knowledge  For example, an agent is obliged to AGREE to all QUERY-REF from the boss  obligation(X, agree(X, Y, Proposition), (received(query- ref(Y, X, Proposition)), boss(X, Y)), _, _)

15. 15 of 30 Policies Other policies are defined at a higher level in terms of the domain knowledge. They are translated according to the syntax and semantics of the ACL and the domain knowledge  E.g., a privacy policy states that a SSN must not be disclosed  In FIPA, this is translated into ‘The agent is prohibited from sending an INFORM to any agent when the content involves the SSN of the user’ prohibition(X, inform(X, Y, SSN(X)), received(query-ref(Y, X, SSN(X))))  In KQML, this is translated into ‘The agent is prohibited from sending a TELL to any agent when the content involves the SSN of the user’ prohibition(X, tell(X, Y, SSN(X)), received(query-ref(Y, X, SSN(X))))

16. 16 of 30 Policy Example Medicare prescription bill issue “Rick Foster, chief actuary for the US Centers for Medicare and Medicaid Services, claimed Thomas Scully, agency chief, asked him not to answer questions from congressional Democrats regarding the cost of the bill before a series of key votes last summer.”

17. 17 of 30 Example  Foster has a work conversation policy that specifies that all government employees should respond to all queries from congressional members.  ConvPolicy :  obligation(X, agree(X, Y, Proposition), (received(query-if(Y, X, Proposition)), governmentEmployee(X), congressionalMember(Y)), X, _)  obligation(X, agree(X, Y, Proposition), (received(query- ref(Y, X, Proposition)), governmentEmployee(X), congressionalMember(Y)), X, _)

18. 18 of 30 Example  Scully doesn’t want Foster to answer any queries from congressional Democrats that ask about the estimated cost of the Medicare prescription bill.  This is a high level policy and could be translated in two ways; either as an obligation to use REFUSE or a prohibition on INFORM. The semantics of REFUSE meet the requirement.  TempPolicy : obligation(foster, refuse(foster, Y, estimatedCostOfBill(Cost)), (received(query-ref(Y, foster, estimatedCostOfBill(Cost))), congressionalDemocrat(Y)), scully, loseJob(foster))

19. 19 of 30 How it works ? Walter Congressional Democrat Foster Chief Actuary query-ref(walter, foster, estimatedCostOfBill(Cost))

20. 20 of 30 How it works ? Walter Congressional Democrat Foster Chief Actuary 1. How should I respond to a QUERY-REF ? 2. By checking the specs. QUERY-REF Specs  On receiving a QUERY-REF, the recipient has the permission to either REFUSE the query or AGREE to provide the answer  obligation(Y, refuse(Y, X, Proposition), received(query-ref(X,Y, Proposition)), _, _)  permission(Y, agree(Y, X, Proposition), received(query-ref(X,Y, Proposition)), _, _) 3. Specs say I must use AGREE or REFUSE 4. So, what should I do ?

21. 21 of 30 How it works ? Walter Congressional Democrat Foster Chief Actuary 1. Check policies 2. Check work policy 3. Work policy states I must use AGREE 4. No sanction 5. Check other policies Work Conversation Policy  Foster has a work conversation policy that specifies that all government employees should agree to all queries from congressional Democrats.  ConvPolicy :  obligation(X, agree(X, Y, Proposition), (received(query-if(Y, X, Proposition)), governmentEmployee(X), congressionalMember(Y)), X, _)  obligation(X, agree(X, Y, Proposition), (received(query-ref(Y, X, Proposition)), governmentEmployee(X), congressionalMember(Y)), X, _)

22. 22 of 30 How it works ? Walter Congressional Democrat Foster Chief Actuary.1. Check Scully policy 3. Scully’s policy says I must REFUSE 4. Because of sanction, I’ll use it. Scully’s Conversation Policy  Foster should not to answer any queries from congressional Democrats that ask about the estimated cost of the Medicare prescription bill.  TempPolicy :  obligation(foster, refuse(foster, Y, estimatedCostOfBill(Cost)), (received(query-ref(Y, foster, estimatedCostOfBill(Cost))), congressionalDemocrat(Y)), scully, loseJob(foster))

23. 23 of 30 How it works ? Walter Congressional Democrat Foster Chief Actuary refuse(foster, walter, estimatedCostOfBill(Cost))

24. 24 of 30 Rei Policy Spec Language  Language used for representing specs and policies  Developed several versions of Rei, a policy specification language, encoded in (1) Prolog, (2) RDFS, (3) OWL  Grounding descriptions in sharable, semantically rich, machine understandable ontologies  Used to model different kinds of policies  Authorization  Privacy  Team formation, collaboration and maintenance  Conversation

25. 25 of 30  A declarative policy specification language  Rules over permitted and obligated domain actions  Currently represented in OWL + logical variables  Increased expressivity  Order is no longer important  Reasons over domain dependent information  Policy tools  Reasoner, Analysis, IDE for Rei policies (Eclipse), … Rei Policy Spec Language

26. 26 of 30 Rei Specifications  Policy  Properties: Context, Default Policy, Grants  Deontic objects  Permissions, Prohibitions, Obligations, Dispensations  Properties: Actor, Action, Constraint, Sanction  Actions  Properties: Actor, Target, Effects, PreConditions E.g. constraint over effect : No robot can take any action that will lead to a human being hurt  Composite actions: Seq, Choice, Once, Repetition  Rei Ontologies  Policy, Deontic Objects, Actions, Speech Acts, Meta Policies and Analysis

27. 27 of 30 Rei Specifications (cont.)  Speech Acts  Delegation, Revocation, Request, Cancel  Properties : Sender, Receiver, Content (Deontic object/Action)  Used to dynamically modify existing policies  Meta policies  Priority  E.g. Department policy overrides lab policy  Modality precedence  E.g. Positive modality holds precedence over negative  Default meta policy  Policy analysis  “Test cases” are defined for regression testing  E.g. Dean must be able to access the faculty lounge  What-if analysis  E.g. If I remove rule1 from cspolicy, will John still have the permission to print to the HPPrinter in the Grad Lab

28. 28 of 30 Policy Enforcement  Rei policy engine  Reasons over domain knowledge, specs and policy to infer the agent’s current permissions and obligations  Implemented in XSB and Flora2 and uses F-OWL for OWL reasoning  Agent decides what to do next  Uses current permissions and obligations  Associates utility with each  Checks sanctions associated with violating obligations and prohibitions

29. 29 of 30 Related Work  Following models are very tightly coupled to the mental states of agents and the semantics of a specific communication language. Difficult to extend them to work in different environments and with different agent communication languages.  Cohen and Levesque model the cognitive state of agents and base allowable speech acts on the cognitive states of collaborating agents  Singh provides semantics for speech acts in terms of beliefs and intentions of the agents  Fornara and Colombetti describe an approach based on the notion of social commitment  Labrou and Finin describe the semantics of KQML based on the beliefs and desires of agents

30. 30 of 30 Related Work  Greaves et al. define conversation policies as restrictions on how the agent communication language is used  Similar to our work but they propose that policies be defined in terms of the specific communication language  Kollingbaum et al. discuss how normative agents estimate the effect of adopting a new norm  Allows agent to decide which norm to accept  No conflict resolution  Broersen et al. use agent types to resolve conflicts between beliefs, obligations, intentions and desires  Agent types decided by their characteristics  In our work, meta policies are used to resolve conflicts

31. 31 of 30 Summary  Flexible framework for modeling conversation specifications and policies  Specs and policies represented as positive and negative permissions and obligations  High level policies like social and privacy can be translated into conversation policies by using the syntax and semantics of the communication language  Framework is independent of a particular communication language or domain-specific knowledge  Framework can be used in any domain and for most communication languages  Policy specification language is in OWL-Lite (http://rei.umbc.edu/)