ModelingConversationPolicies using PermissionsandObligations - PowerPoint PPT Presentation

Title: ModelingConversationPolicies using PermissionsandObligations


1
Modeling?Conversation?Policiesusing
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/

2
Outline

• Key Idea
• Our Approach
• Introduction
• Framework
• Example
• Policy Specification Language
• Policy Enforcement
• Related Work
• Summary

3
Key Idea

• Key idea Its 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
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
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
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
Specifications

• Agents communicate via communicativeacts (CAs)
  to fulfill collaborative goals
• A conversation is a sequence ofCAs between
  agents towards satisfyinga 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
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
Specs Vs Policies

• Specs define all possibilities,
• Ideally, higher policies narrow whats allowed
  and broaden whats required.
• But theres room for conflict
• We assume that conversation policy is always of
  higher priority than the specs

10
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
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
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
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
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
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
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
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
Example

• Scully doesnt 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
How it works ?
query-ref(walter, foster, estimatedCostOfBill(Cost
))
Walter Congressional Democrat
FosterChief Actuary
20
How it works ?
1. How should I respond to a QUERY-REF ? 2. By
checking the specs.
3. Specs say I must use AGREE or REFUSE 4. So,
what should I do ?
Walter Congressional Democrat

• 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)), _, _)

FosterChief Actuary
21
How it works ?
1. Check policies 2. Check work policy
3. Work policy statesI must use AGREE4. No
sanction 5. Check other policies
Walter Congressional Democrat

• 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, _)

FosterChief Actuary
22
How it works ?
.1. Check Scully policy
3. Scullys policy saysI must REFUSE 4. Because
of sanction, Ill use it.
Walter Congressional Democrat

• Scullys 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))

FosterChief Actuary
23
How it works ?
refuse(foster, walter, estimatedCostOfBill(Cost))
Walter Congressional Democrat
FosterChief Actuary
24
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
Rei Policy Spec Language

• 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),

26
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,
  MetaPolicies and Analysis

27
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
Policy Enforcement

• Rei policy engine
• Reasons over domain knowledge, specs and policy
  to infer the agents 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
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
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
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/)