ModelingConversationPoliciesusing

PermissionsandObligations

ModelingConversationPoliciesusing

PermissionsandObligationsLalana Kagal and Tim FininUniversity of Maryland, Baltimore CountyAAMAS Workshop on Agent Communication, NYC, 19 July 2004http://ebiquity.umbc.edu/v2.1/event/html/id/42/http://creativecommons.org/licenses/by-nc-sa/2.0/

Lalana Kagal and Tim FininUniversity of Maryland, Baltimore CountyAAMAS Workshop on Agent Communication, NYC, 19 July 2004http://ebiquity.umbc.edu/v2.1/event/html/id/42/http://creativecommons.org/licenses/by-nc-sa/2.0/

2 of 30

OutlineOutline

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

3 of 30

Key IdeaKey IdeaKey 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 of 30

Our ApproachOur 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 of 30

Our ApproachOur ApproachDeclarative 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 of 30

Our ApproachOur 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 of 30

SpecificationsSpecificationsAgents communicate via communicative

acts (CAs) to fulfill collaborative goalsA conversation is a sequence of

CAs 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 of 30

PoliciesPolicies 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 of 30

Specs Vs PoliciesSpecs 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 of 30

FrameworkFramework 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 of 30

Example Specification: FIPA QUERY-REF

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

FIPA QUERY-REFFIPA 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 of 30

FIPA QUERY-REFFIPA 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 of 30

PoliciesPolicies 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 of 30

PoliciesPoliciesOther 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 of 30

Policy ExamplePolicy 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 of 30

ExampleExample 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 of 30

ExampleExampleScully 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 of 30

How it works ? How it works ?

Walter Congressional Democrat

FosterChief Actuary

query-ref(walter, foster, estimatedCostOfBill(Cost))

20 of 30

How it works ? How it works ?

Walter Congressional Democrat

FosterChief Actuary

1. How should I respond to a QUERY-REF ?2. By checking the specs.

QUERY-REF SpecsOn 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 REFUSE4. So, what should I do ?

21 of 30

How it works ?How it works ?

Walter Congressional Democrat

FosterChief Actuary

1. Check policies2. Check work policy3. Work policy statesI must use AGREE4. No sanction5. Check other policies

Work Conversation PolicyFoster 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 of 30

How it works ?How it works ?

Walter Congressional Democrat

FosterChief Actuary

.1. Check Scully policy3. Scully’s policy saysI must REFUSE4. Because of sanction, I’ll use it.

Scully’s Conversation PolicyFoster 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 of 30

How it works ?How it works ?

Walter Congressional Democrat

FosterChief Actuary

refuse(foster, walter, estimatedCostOfBill(Cost))

24 of 30

Rei Policy Spec LanguageRei 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 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 informationPolicy tools

Reasoner, Analysis, IDE for Rei policies(Eclipse), …

Rei Policy Spec LanguageRei Policy Spec Language

26 of 30

Rei SpecificationsRei Specifications Policy

Properties: Context, Default Policy, Grants

Deontic objects Permissions, Prohibitions,

Obligations, Dispensations Properties: Actor, Action,

Constraint, Sanction Actions

Properties: Actor, Target, Effects, PreConditionsE.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 of 30

Rei Specifications (cont.)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 of 30

Policy EnforcementPolicy 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 of 30

Related WorkRelated 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 of 30

Related WorkRelated 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 of 30

SummarySummary 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/)