Supervised Interaction – Creating a Web of Trust for Contracting Agents in Electronic Environments Martin J. Kollingbaum
Timothy J. Norman
Department of Computing Science University of Aberdeen Aberdeen, AB24 3UE, Scotland, UK
Department of Computing Science University of Aberdeen Aberdeen, AB24 3UE, Scotland, UK
[email protected]
[email protected]
ABSTRACT Supervised interaction is concerned with the problem of establishing trust between contracting agents in electronic markets. Agents act as representatives of their organisations or of individuals, negotiate contracts for the supply of goods and services and manage their delivery. It is essential for the automation of business transactions to put safeguards in place that ensure that errant behaviour is either prevented or sanctioned. The model proposed in the paper – Supervised Interaction – consists of three elements: an organisational framework, a contract specification language and a contract management protocol. The organisational framework emphasises the importance of introducing a trusted third party into any automated business transaction. Three essential roles are, therefore, proposed: the addressee, counter-party and authority. The normative positions of the agents involved in an automated business transaction are explicitly expressed within the contracts that govern agents’ behaviour during supervised interaction. This interaction model is designed to provide the web of trust necessary for successful deployment of agent-mediated electronic markets.
Keywords Electronic Commerce, agent organisations, norms and institutions.
1. INTRODUCTION Agent-mediated electronic commerce uses software agents to automate human business activities. Agents meet in virtual environments for the purpose of performing business transactions by offering services and goods, negotiating deals and initiating the exchange of commodity for money. This move towards automation is driven by the need to exploit larger markets, operate more efficiently, and allow the formation of short-term coalitions with a greater variety of potential business partners, all with the motivation of acquiring a greater market share. Supervised Interaction deals with the problem of establishing trust
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AAMAS ’02, July 15-19, 2002, Bologna, Italy. Copyright 2002 ACM 1-58113-480-0/02/0007…$5.00.
between agents acting in open electronic markets. Such markets provide environments where agents, under the command of different human organisations, may meet and interact [6, 22]. Individuals take on different roles such as buyers, sellers, auditors, information vendors, financial institutions and other intermediaries. The “exchange of money for commodity” is always a delicate issue, and even more so when automated because of the loss of direct human control over the process. It is because of this that marketplaces must be able to evaluate participants and to maintain data about their reputation, creditworthiness, capabilities and experience, prices, availability, current and past business transactions, and information important for authorities and regulators [1]. The traditional means to secure business transactions are contracts [8]. They form a normative framework that makes explicit the dependencies between individuals in their social context. The social context provides a means of control and law enforcement to sanction defective (or non-ideal) behaviour [10]. In electronic environments, contract negotiation takes place in an automated fashion by agents. Whatever deals these agents negotiate, their human organisations will eventually be held responsible. The fundamental problem is that current contract management models are unsuited to dealing with defective behaviour of individuals; agent interaction is often based on the assumption that agents involved will not display unexpected behaviour. It is, therefore, essential that either potential trading partners are recognizable as trustworthy, or mechanisms to establish trust are put in place. The importance of mechanisms of trust in electronic environments is widely recognised [4, 14, 24]. Castelfranchi et al. [2, 4] emphasise the importance of a witness or “trusted third party” in the contracting process and as a means to enforce social commitments. As a third force, it enables the creation of relationships between two contracting agents under a situation of trust. For instance, in [2] social commitment is proposed as a three-party relationship, where the third party is the witness to the two agents that are the producer and consumer of a commitment to act. This is the key to a powerful means to create trust and secure interactions in agent societies and it is used as a basic element in Supervised Interaction. A tripartite organisation is also a well-known pattern for securing electronic communication; for example, a digital certificate authority may act as a trusted third party to guarantee the integrity of a message. Through cryptographic methods, a certain level of trust may be established for business transactions. Supervised Interaction builds on this “message layer” to consider the
knowledge layer where the focus is on the normative positions of agents, contract execution monitoring and the imposition of sanctions. The model introduced here provides the necessary tools for automated contracting: an organisational framework, a contract specification language and a general contract management process. The organisational framework, described in section 2, follows the three-party pattern, where agents take on one of three roles: authority, addressee and counter-party (see figure 1).
Authority
•
•
The addressee, one of the parties under observation by the authority, takes on a commitment to provide goods or a service (the supplier). In return, the addressee gains certain rights over the counter-party regarding timely payment or some other appropriate recompense for the service or goods provided. The counter-party, again under observation by the authority, is the recipient of the goods or the service, and, therefore, gains certain rights over the addressee under the contract. Furthermore, the counter-party commits to providing appropriate payment.
Trust
Counter-Party
Addressee
Customer
Supplier
Agent 1 Authority
Agent 4
Reputation Agent 2 Addressee
Figure 1. Three-Party Relationship.
Flow o f
The contract management process, presented in section 4, operates in three principle phases. During the initial registration phase, the coalition between authority, addressee and counter-party is formed and the context for the following phase (negotiation) is agreed. Possibly building on so-called “Contract Templates” (see section 3), the issues within a contract are negotiated by the addressee and counter-party. The completion of this phase is characterised by the signing of the contract and registering it with the authority. The authority then monitors the execution of the contract (the third and final phase of Supervised Interaction), manages complaint procedures, and, possibly, imposes sanctions. This registration, establishment (including negotiation) of a contract, lodging of the contract with the authority and management of its execution is the third component of Supervised Interaction – the general contract management process. These three elements: organisation, contract specification and contract management are the key components of this paper and represent (as a whole) its primary contribution.
2. ORGANISATION The general pattern of a safeguarding mechanism used in traditional contracting is used as the model for Supervised Interaction. Agents are organised in a three-party relationship between two contracting individuals (or organisations) and a trusted third party, or authority. Supervised Interaction depends on this organisational structure, and is designed to dissuade defective behaviour and create a web of trust for automated business transactions. During Supervised Interaction, agents take on one of the addressee, counter-party or authority roles: •
The authority acts as the witness to the contract and as a norm-enforcing entity. This trusted third party is involved as a supervisory element, and the general model of interaction proposed here depends on the existence of this supervision.
Authority
Counter-Party Agent 3
Goods
Flow o f
The contract specification language, introduced in section 3, is used to declare the normative positions of signatories to a contract. A contract, therefore, describes the rights of agents with respect to activities involved in the execution of the contract.
Contract
Addressee
? Agent 6
Money
? Recommendation Agent 5
Counter-Party
Addressee Contract Negotiation
Social Context Figure 2. Social Context of Supervised Interaction These roles are attributed to agents by contracts, describing their qualities and deontic characterisations. A contract is a method of specifying the rights of an agent in such a role: its obligations, permissions and prohibitions. The social context is the normative background for the creation and execution of such contracts - in the real world, contract law provides part of this social context. Figure 2 illustrates the essential mechanisms and elements of Supervised Interaction in its social context. This social context provides the normative background for contract creation and execution and a means of law enforcement. Agents engage in Supervised Interaction by taking on the role of the addressee, counter-party or authority in a specific encounter. However, an agent may, for example, take on the role of the counter-party in one encounter and that of the addressee in another (see agent 3 in figure 2). In figure 2, agent 1 acts as the authority and agent 2 and 3 as the contracting partners for the illustrated contract. In this encounter, agent 2, the addressee, has been contracted to deliver a service or goods to agent 3, the counter-party for this transaction. This establishes a "Flow of Goods" from agent 2 to agent 3 (and a "Flow of Money" in the opposite direction). This exchange takes place under the supervision of agent 1, the authority. By establishing another Supervised Interaction encounter, as illustrated between agent 3, 4 and 6, goods may flow further downstream. This, therefore, illustrates a part of a supply chain. Figure 2 also illustrates issues such as reputation of agents taking on authority roles or agents being recommended as a potential supplier or customer. These are important issues within contract management in general, but are outside the scope of this paper.
::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=
“contract” “(“ “,” ( | )+ “,” ( )+ “)” “agent” “(“ “,” “)” “role” “(“ “)” | | “obligation” “(“ “,” “,” “,” “)” “permission” “(“ “,” “,” “,” “)” “sanction” “(“ “,” “,” “,” “)” | | | “do” ( “,” “)” “achieve” “(” “,” “)” “not_do” “(“ “,” “)” “not_achieve” “(“ “,” “)” ( (“and” | “or”) )*| “not” “(“ “)” | “(“ “)” | “TRUE” | “FALSE”
Figure 3. BNF Syntax of the Contract Specification Language
During the execution of a contract, the authority (the agent taking on the authority role) observes the behaviour of the contracting agents. In case of defection, the authority has the power to impose the sanctions specified in the contract (see section 3). The authority may not impose a sanction unless it is specified in the contract and only the authority may impose sanctions. In some cases this may be by reporting the defection to the organisation it represents to involve human intervention. This indicates a need for legal and financial institutions to become involved in electronic markets and offer such authority services. Supervised Interaction between agents is based on a three-party relationship, but it depends on the nature of the contract how much the third party is involved. Business transactions in electronic markets range from mass product or “off-the-shelf” purchases to the purchase of single specialized products from a small group of potential suppliers. If there is a commodity/service provided by many suppliers then it would be reasonable for customers to simply advertise their needs against an anonymous crowd of suppliers. In such business transactions, the trusted third party may provide, for example, an auction service, such as the market model proposed by Dellarocas [6] or the Fishmarket [22, 15, 21]. In transactions where customers have to deal with one or two specialised suppliers (e.g. contracts to supply aircraft engines), it will be a matter of detailed negotiation between few agents. These examples illustrate the extremes, but in all cases, some form of trusted third party is necessary to secure a business transaction. Before the contract management process is discussed in detail, the approach for contract specification, the second key issue of Supervised Interaction, is outlined in the next section.
3. CONTRACT SPECIFICATION As argued in the previous section, contracts are important in the establishment of trust between the trading agents. Contracts specify norms that guide their behaviour during the exchange of goods and services. Supervised Interaction is designed to facilitate the creation and management of binding contracts between agents, and hence between the human organizations represented by these agents. These contracts must, therefore, capture the essence of real contracts between human organizations in a form that may be interpreted and executed by agents. Two concepts are introduced here for this purpose: “Contract Templates” as pre-fabricated contract outlines encoding domain-independent interaction
schemata or “business protocols”, and a specification language to encode these Contract Templates. Contract Templates provide a formalized way to describe business protocols such as the “Letter of Credit” protocol, which is a well-known interaction schema in the business world and is used to secure transactions. Contract Templates encode these business protocols or services in a domain-independent way. The actual contract is instantiated from these templates during a negotiation phase between the agents involved. For this purpose, Contract Templates contain “place holders” or variable elements such as price, quantity, deadlines, quality constraints or required technical properties and the actual contracting partners/agents; these are the domain-specific parameters that are instantiated during the registration and negotiation phases of Supervised Interaction. Determined during Registration Phase
Domainindependent Template
Domainspecific Parameter
Contract =
Negotiation Agreement
Figure 4. Contract Template and instantiated Contract As introduced previously, and discussed in detail in the following section, the contract management process comprises the three phases “registration”, “negotiation” and “contract execution”. In the registration phase, the contracting partners determine the constraints on the nature of the good or service to be delivered. This results in an “Agreement in Principle” to supply those services or goods (see section 4.1). The elements that are then open to negotiation – such as price or delivery time – are agreed during the negotiation phase. Using this model, relatively simple negotiation mechanisms may be employed. In fact, no negotiation mechanism is necessary; for example, the supplier may simply quote the price from a catalogue and the customer may select from a set of available delivery times. It is important to emphasize that
contract ( LoC_execution, role ( ?customer ) role ( ?supplier ) role ( ?bank ) obligation ( customer_account_request, do ( ?customer, open_LoC_account
permission (
obligation (
(
TRUE, granted ( ?account_no ) ) customer_account_reply, do ( ?bank, provide_account account_request_received ( ?customer ), granted ( ?account_no ) ) customer_deposit, do ( ?customer,transfer_deposit
?bank, ?customer ) ),
( ?account_no ) ),
(
?bank, ?account_no, ?amount_deposit ) ),
granted ( ?bank, ?account_no ), deposit_transferred ( ?customer, ?amount_deposit ) ) … … sanction (
sanction (
withhold_deposit, do ( ?bank, withhold_deposit ( ?supplier ) ), not received_before ( ?delivery, ?deadline ), received_before ( ?delivery, ?deadline) ) blacklist do ( ?bank, put_on_blacklist ( ?supplier ) ), not received_before ( ?delivery, ?deadline ), received_before ( ?delivery, ?deadline ) )
)
Figure 5. Fragment of a Contract Template
Supervised Interaction does not rely upon any specific negotiation mechanism to complete the instantiation of a Contract Template. The negotiation mechanism employed in a specific scenario may be an auction protocol, a reverse auction or a more sophisticated argument-based negotiation mechanism. To enable the specification of Contract Templates that capture the essence of real contracts, a contract specification language is presented in this paper. This language takes its influences from the Philosophy of Law, where formal languages are used to specify legal positions [13, 19], and the use of these languages, and extensions of them, in the specification of computer systems [10, 11, 17]. The remainder of this section is used to motivate the different constructs of our language and their purpose. The contract specification language is built upon a number of key elements: agent-role assignment, obligations, permissions and sanctions. In general, a contract contains role specifications to clearly determine the contracting parties and the norm specifications relevant to them. Regarding the model of Supervised Interaction, contracts with the three specific role specifications “authority”, “addressee” and “counter-party” are considered. A syntax specification of this language is outlined in figure 3. The language constructs are used to express normative positions associated with each role and the sanctions that may be imposed following defective behaviour. The language constructs for obligations, permissions and sanctions have a similar structure – it is the interpretation of these contract elements that differ. Of particular importance are the , the condition and the condition of these contract elements. As can be seen in figure 3, an obligation (and similarly permission and sanction) has the following structure:
obligation ( o, achieve ( r, p ), s, e) obligation ( o, not achieve ( r, p), s, e) obligation ( o, perform ( r, a), s, e) obligation ( o, not perform ( r, a), s, e) where o is a unique obligation identifier, r is a role identifier, p is an expression describing the desired state of affairs, a describes an action, s is the activation condition of this obligation and e the expiration condition. The in these norm constructs allows the formulation of statements such as “agent x sees to it that the state of affairs p holds” and “agent x sees to it that the action a is performed”. In other words, it provides that flexibility to distinguish between the achievement of goals and the performance of action, as outlined in detail in [16]. An act expression associates a specific role (and hence a specific agent in an instantiated contract) with a specific activity. Furthermore, the language allows the expression of, for example, obligations of particular roles (and hence agents) to not achieve states of affairs and to not perform acts. An act expression may, therefore, have one of four different forms: • • • •
An agent (taking on some role) sees to it that a state of affairs is achieved. An agent does not see to it that a state of affairs is achieved An agent sees to it that an action is performed An agent does not see to it that an action is performed
It is worth noting here that, following theoretical models of these act expressions, stating that an agent sees to it that a state of affairs is achieved does not force the agent concerned to actually
achieve the state of affairs. It may do so, but it may also delegate this activity to some other agent. It does, however, remain responsible for its achievement [16]. Both and are conditions, which are defined as states of affairs. The activation condition is the state of affairs in which the obligation, permission or sanction becomes operative. The expiration condition is that state of affairs in which the associated obligation, permission or sanction ceases to be operative. Taking permission first, this means that the activation and expiration conditions describe a window of opportunity, within which the agent may act. For obligation, they delimit the period in which the agent must act (possibly giving deadlines for the fulfillment of an obligation). These specifications of obligation and permission are connected to a specific “role” and therefore represent the deontic characterisation of that role.
sanction is activated – in case that the goods are not delivered in time. The expiration condition looks very similar, which is intentional, because it specifies that the sanction immediately expires (and is, therefore, never active) if the goods arrive on time. In case of defective behaviour, its action part may be executed by the authority. More subtle specifications would maybe include contingency behaviour as part of the contract to allow e.g. recovery from such a situation without terminating the contract execution.
4. CONTRACT MANAGEMENT The contract management process is the third key element of Supervised Interaction. It guides agents willing to interact under supervision through a sequence of activities that bind together a set of agents for contract negotiation and execution.
One of the key elements to the contract specification language proposed is the explicit specification of sanctions within a contract. Sanctions describe actions that may be taken (or not taken) or states of affairs that may be achieved (or not achieved) within a particular window of opportunity. Moreover, any obligation must be accompanied by at least one sanction, as obligations without sanctions are in-effective in determining the actions of an agent. There are two important differences between sanctions and permissions: • •
Registration
Contract Negotiation
The result of the negotiation phase is a contract – an instantiated Contract Template. The fragment of such a template is illustrated in figure 5 and shows the “Letter of Credit” protocol encoded in the contract specification language. The template contains role specifications and declarations of obligations, permissions and sanctions. Variable elements such as ?delivery or ?deadline are subject to negotiation. An instantiated contract will contain explicit information instead of these placeholders. The first obligations for the customer role (as part of a “Letter of Credit” specification) are outlined. The obligation customer_account_request determines that the customer must deposit the money for the purchase with the bank (the authority). This amount is subject to negotiation and therefore one of the variable elements of the Contract Template. This obligation specification therefore contains an action specification for the customer to open a “Letter of Credit” account with the bank. The activation condition for this obligation is specified here as TRUE, which means that this would be the first norm activated as soon as the contract execution is started by the agents. This obligation is fulfilled, or expires, as soon as the account is granted. As the following permission specification (indicating that the bank “is allowed” to grant such a request) has the same expiration condition; both norms expire at the same time. Two sanctions are illustrated, the first describing a withhold_deposit action in case of defection. Its activation condition specifies when this
Negotiate Contract using Contract Template
Contract
A permissions must be consistent with other permissions and obligations specified in the contract. A sanction can override any obligation or permission specified in the contract. This means that, for instance, a sanction could be defined as the removal of a permission.
Often, the imposition of a sanction becomes an option (for the authority in the case of Supervised Interaction) if one of the contracting agents does not act according to its obligations.
Agree on Level of Supervision Register with Authority
Contract Execution
Execute Contract under observation by the Authority
Figure 6. Contract Management Process This management activity takes place in three main phases: registration, contract negotiation and contract execution. •
•
•
Registration. In the registration phase, two agents taking on the role of addressee and counter-party identify their need to engage in a transaction under the supervision of a third party. The next phases of contract management require that they agree in principle on issues open to negotiation. These agreements will determine the type of service required from the third party and the purpose of the contract that will be negotiated in the following phase. The type of service is expressed as a Contract Template put forward by the authority to the two contracting agents. Contract negotiation. This phase is focused on the domainspecific content of the contract following the template agreed in the registration phase. Issues determined important in the registration phase must be negotiated, for example price, quality or delivery dates. Contract execution. The fully negotiated contract is executed by the three agents under the supervision of the authority.
Figure 6 shows the three phases of Supervised Interaction. In the registration phase, two agents will find a special agent that can provide an “authority service” (like a notary or a bank). If such an authority is chosen, both agents can engage in a contracting process that yields a contract. This contract is then executed under the observation of the authority. This process can only be finished if agreements can be found in each of the phases. The registration phase can create the setup for subsequent phases, but the whole
process may fail, if for example the agents find no agreement in the negotiation phase. The process must then be re-initiated with a new registration attempt. In the execution phase, defective behaviour of one of the agents could result in the imposition of the sanctions declared in the contract, and if so, this may also disrupt the process. These three phases are explained in detail in the following sections.
4.1 Registration Phase The goal of the registration phase is to set up three-party relationships between contracting agents and an authority. Registration involves four stages (the following is discussed from the point of view of a customer initiating the contracting process because of its interest in the supply of a specific commodity or service). •
• •
•
Match-making. The customer identifies potential suppliers or sources of supply (such as a specific auction house). This results in a set of potential suppliers that the customer is prepared to do business with. Deciding upon the “Level of Supervision”. This level of supervision is the service that is provided by an authority; i.e. the Contract Template that the authority supports. Instantiating the domain independent Contract Template with the details of the commodity or service that is the object of the contract and identifying the issues that are open to negotiation. Signing and “Agreement in Principle”. Either the customer signs up with an authority that is responsible for the running of an auction house, or the customer and supplier(s) sign up with an authority that is prepared to oversee the contracting process. On successful completion of this stage, an “Agreement in Principle” exists between a single authority, a single Contract Template and negotiation mechanism and the customer(s) and supplier(s) as shown in figure 7.
Three contracting situations are considered here, reflecting three broad classes of negotiation mechanism: 1. 2.
3.
One customer, many suppliers. This is typical in negotiation mechanisms such as the well-known Contract Net Protocol. Many customers, one supplier. This is typical in classical auctions such as the Dutch Auction used in the FishMarket system [22, 15, 21]. One customer, one supplier. This contracting situation is more likely in a situation where the service or commodity required is specialised, and more sophisticated argumentbased negotiation mechanisms may be employed. This is also typical where there are few (if any) issues open to negotiation; for example, the identified supplier is willing only to give a “take-it or leave-it” quotation and a set of possible delivery times.
In each of these cases, the participants agree on a single authority. In the first case (one customer, many suppliers), the customer will simply propose the authority, the Contract Template (partially instantiated with the details of the commodity or service required) and the negotiation mechanism (e.g. the Contract Net Protocol). The potential suppliers may then indicate their willingness or unwillingness to be involved in the contracting process. An indication of willingness is considered to be its assent to this agreement in principle to be involved in the proposed contracting
process. The agreement in principle is, therefore, of the form 1:N given in figure 7. In the second case, the customer assents to the rules of the auction and the Contract Template supported by the authority offering this auction service. By going through the “signing on” process involved in entering the auction house, the agent agrees to the rules of the auction: the negotiation mechanism and the Contract Template. By engaging in a specific auction within that auction house, the customer instantiates the Contract Template with the details of the commodity being auctioned. In such a situation, it is typical for the only issue open to negotiation to be the price of the commodity being auctioned. The third situation is of particular interest to the work presented in this paper because, as indicated above, it includes the situation in which there are no issues open to negotiation, except, possibly, agreeing on a mutually acceptable delivery time. A negotiation mechanism is not a necessary component of Supervised Interaction. (Note that, in this paper, an auction or reverse auction is considered to be a minimal negotiation mechanism.) In the situation where the customer has identified a particular potential supplier, they then proceed to identify an acceptable level of supervision (or a Contract Template that they are both prepared to use as the basis for the contracting process) and determine an authority that can support this Contract Template. The Contract Template can then be partially instantiated with the details of the commodity or service.
Agreement in Principle customer, supplier, authority, contract template, negotiation mechanism
Combination of:
1:N
N:1
(c, {s}, a, t, n) CNP Reverse Auction
({c}, s, a, t, n) Auctions Fish Market
1:1
(c, s, a, t, n) Argumentation-based Negotiation
Figure 7. Agreement in Principle The choice of an authority is similar to that of a supplier; the authority itself is a supplier of services. Service fees and reputation are typical criteria. The authority, when approached, must decide, if it is capable and willing to provide its services, depending on, for example, its current volume of business. The authority may even offer different services; it may support different Contract Templates. With an “Agreement in Principle” established, the agents involved in the contract management process may then proceed to the next phase: negotiation.
4.2 Negotiation Phase The negotiation phase uses the “Agreement in Principle” as a basis for the production of a complete contract for execution. According to the negotiation mechanism agreed upon, the customer(s) and supplier(s) complete the instantiation of the Contract Template.
The specification of specific negotiation mechanisms is, however, outside the scope of this paper. As already mentioned, the process of Supervised Interaction is not dependent on any particular model of negotiation dialogue. Anything from the insertion of the cost of the commodity or service from a catalogue and the selection between available delivery times through an auction protocol to a sophisticated argument-based dialogue could equally be used [12, 18]. The participants must, of course, support this mechanism. On successful completion of this phase, the customer and supplier lodge the instantiated contract with the authority, and each of the three parties to the “signed” contract may proceed to the execution phase.
4.3 Execution Phase The “signed” contract contains declarations of obligations, permissions and sanctions of each party following the template used. These declarations will guide the execution of the contract. The execution phase can be demonstrated with the “Letter of Credit” protocol that is well established in the business world. It is employed in situations where there is no trust between business partners, but they (individually) trust the third party. The Letter of Credit proceeds as follows: 1.
2. 3. 4. 5. 6. 7.
Customer deposits money with authority (the bank in this example illustrated in the Contract Template fragment in figure 5) Customer receives a Letter of Credit Authority informs supplier about Letter of Credit Supplier transfers commodity to customer Customer gives LoC to supplier Supplier sends LoC to authority Authority hands over money to supplier
The illustration in figure 5 shows two obligations and a permission guiding the behaviour of the customer and the bank agent in terms of establishing step one of this process. The customer requests a LoC account with the bank. Following the request by the customer, the bank is permitted to respond by providing such an account. If the bank does provide an LoC account, the customer is obliged to deposit the agreed amount as specified in the contract. Two sanctions are shown in this Contract Template fragment. The bank may withhold the deposit from the supplier, if it is not the case that the goods are delivered before the deadline. It may not withhold the deposit under any other circumstances; this sanction expires if the delivery does arrive on time. The second sanction illustrated has the same activation and expiration conditions, but refers to the option of placing the supplier on a blacklist. It is worth re-emphasizing at this point that sanctions can override any other obligation on the bank or permission of any other agent involved in the contract. This protocol introduces a strict regime regarding the flow of money between customer and supplier. The bank acts as an intermediary and provides a deposit service. The money will be handed out under fixed circumstances.
5. RELATED WORK This paper is based on three bodies of related work: (a) normative system specification, (b) agent-mediated electronic commerce,
electronic institutions and virtual organisations and (c) models of trust and reputation. Jones and Sergot [10, 11] and Pacheco and Carmo [17] (influenced, among others, by the seminal works of Lindahl [13], Pörn [19]) investigate the modelling of complex organisations and organisational behaviour using normative models. Pacheco and Carmo emphasise the importance of contracts as the central element to bind agents into societies. They analyse human institutions to derive properties relevant for contract specification. They describe the concept of a “role” taken on by agents as essential for modelling such an agent society. Contracts bind agents to specific roles within an institution. Roles correspond to qualities of agents and are associated with the deontic notions of obligation, permission and prohibition (cf. the specification of roles and relationships discussed in [5, 22]). The contract specification language put forward by Pacheco and Carmo includes role specifications, deontic characterisations for these roles, statements of representation, the attribution of roles to agents and the relations between roles. In this paper, we explore extensions to this contract specification language. We consider the explicit specification of sanctions that may be imposed by the specific “authority” role introduced in Supervised Interaction. We also consider explicit activation and expiration conditions for normative statements in a contract, to clearly specify the time window during which a normative activity is operative. Dellarocas [16] proposes the “Contractual Agent Societies” as a model for building open multi-agent market systems. In such societies, agents representing different interests join a virtual institution, where they may organise themselves through a set of dynamically negotiated contracts. An agent that joins a society undergoes a process of “socialisation”, and a set of contracts defines the shared context for interaction with members of the society. Contractual agent societies, therefore, are an abstraction of systems such as the fish market [22, 15, 21]. Agents entering the fish market undergo a registration process (socialisation) and interact (albeit through a specific market protocol) in the establishment of contracts for the sale of boxes of fish. The contractual agent society model, in common with the fish market, provides a means of social control that discourages agents from violating their commitments by detecting defective behaviour by reporting to reputation agents. Dellarocas specifies contracts in terms of beliefs, preferences and objectives. As already mentioned, agents engage in business transactions only, if there is a certain level of trust between the business partners. Even if such transactions become more and more automated, the agents still act on behalf of human organisations and, eventually, these organisations will be held responsible for the activities of their agents. Castelfranchi and Falcone [3] state that “[t ]rust is as important in multi-agent systems as it is in human societies. The notion of an agent implies the concept of delegation and delegation is based on trust.” According to Castelfranchi (and others, e.g. Marsh [14]), trust is a mental attitude, where delegation is an action that results in a specific “trusted” relationship between agents. Models of trust are established as a means for estimating the “trustworthyness” of agents. A number of attempts to quantify trust for this purpose are presented in literature ([3, 14, 24]). Yu and Singh [24] describe a model of reputation or trust management that is influenced by techniques used in recommender systems [20]. They model an electronic community, where agents assist users by maintaining
contact to other agents and recommending potential and trustworthy partners. The reputation of a participant in such a community depends on capability (or expertise) and helpfulness. Agents will recommend the most helpful and reliable parties. To build and manage representations of trust, agents accumulate their own experience with a specific participant and combine it with reputation transmitted from other agents. A model of quantifying, or identifying in some way, the level of trust of one agent in another agent with respect to specific activities is not presented in this paper. Rather, the interest of this work is focused on a development of a machinery that will produce upfront saveguards that generate a web of trust around a transaction between two interacting agents: the “addressee” and the “counter-party”.
6. CONCLUSION In this paper, Supervised Interaction is proposed as a general pattern of agent contracting. This form of interaction is designed to provide the web of trust necessary for successful deployment of agent-mediated electronic markets. The three key elements of Supervised Interaction have been presented in this paper. The first element is a specific organisation involving three basic roles - the addressee, the counter-party, and the authority as a "trusted third party". The second element is a contract specification language. Contract Templates, defined using this language, are used within the contract management process, the third element of Supervised Interaction. During this process, agents register with an authority, negotiate the details required for the instantiation of a Contract Template, and execute this contract under the supervision of the authority.
REFERENCES [1] Feldman, S. (2000), Electronic Marketplaces, IEEE Internet Computing, July/August 2000 [2] Castelfranchi, C. (1995). Commitments: From Individual Intentions to Groups and Organizations, Proceedings of the First International Conference on Multi-Agent Systems ICMAS’95, San Francisco, 1995 [3] Castelfranchi, C., Falcone, R. (1998). Principles of Trust for MAS: Cognitive Anatomy, Social Importance, and Quantification, ICMAS’98, 1998 [4] Castelfranchi, C., Tan, Y.-H. (2001), The Role of Trust and Deception in Virtual Societies, Proc. 34th Hawaii Intl. Conf. On System Sciences, 2001 [5] Cavedon, L., Sonenberg, L. (1998). On social commitment, roles and preferred goals. In Proceedings of the Third International Conference on Multi-Agent Systems, pages 8086, 1998. [6] Dellarocas, D. (2000). Contractual Agent Societies: Negotiated Shared Context and Social Control in open Multi-agent Systems, 2000 Workshop on Institutions and Norms in MAS, Autonomous Agents 2000, Barcelona, Spain, 2000 [7] Dignum, F., Morley, D., Sonenberg, E.A., Cavedon, L. (2000). Towards socially sophisticated BDI Agents, ICMAS 2000, pp.111-118, 2000 [8] Jennings, N.R., Faratin, P., Norman, T.J., O’Brian, P., Odgers, B. (2000). Autonomous Agents for Business Process Management. International Journal of Applied Artificial Intelligence, 14(2):145-189.
[9] Jennings, N.R., Parsons, S., Sierra, C., Faratin, P. (2000). Automated Negotiation, Proc. 5th Int. Conf. On the practical Application of Intelligent Agents and Multi-Agent Systems (PAAM-2000), Manchester, UK, 2000 [10] Jones, A.J.I., Sergot, M. (1992), On the Characterisation of Law and Computer Systems: The Normative Systems Perspective, In J.-J.Ch. Meyer, R.J. Wieringa (editors), Deontic Logic in Computer Science: Normative System Specification [11] Jones, A.J.I., Sergot, M. (1996), A Formal Characterisation of Institutionalised Power, Journal of the IGPL, 4(3), pp.429445, 1996 [12] Kraus, S., Sycara, K., Evenchil, A. (1998). Reaching agreements through argumentation: A logical model and implementation. In Artificial Intelligence, 104, pages 1-69, 1998. [13] Lindahl, L. (1977). Position and Change, D. Reidel Publishing Company, Dordrecht-Holland/Boston-U.S.A., 1977 [14] Marsh, S.P. (1994). Formalising Trust as a Computational Concept, PhD Thesis, University of Stirling, 1994 [15] Noriega, P. (1997), Agent Mediated Auctions: The Fishmarket Metaphor, PhD Thesis, Universitat Autonoma De Barcelona, 1997 [16] Norman, T.J., Reed, C. (2000). Delegation and Responsibility, UKMAS 2000, Oxford, 2000 [17] Pacheco, O., Carmo, J. (2001). A Role Based Model for the Normative Specification of Organized Collective Agency and Agents Interaction, Journal of Autonomous Agents and Multi-Agent Systems, in press, 2001 [18] Parsons, S., Sierra, C., Jennings, N.R. (1998). Agents that reason and negotiate by arguing, In Journal of Logic and Computation, 8 (3) 261-292, 1998. [19] Pörn, I (1970), The Logic of Power, D. Reidel Publishing Company, Dordrecht – Holland, 1970 [20] Resnick, P.,Varian, H.R. (1997). Recommender Systems, Commun. ACM, 40(3):56-58. [21] Rodriguez, J.A., Noriega, P., Sierra, C., Padget, J. (1997). FM96.5 A Java-based Electronic Auction House, Proceedings of the Second International Conference on the Practical Applications of Intelligent Agents and Multi-Agent Technology (PAAM-97), 1997 [22] Sierra, C., Dignum, F. (2001), Agent-Mediated Electronic Commerce: Scientific and Technological Roadmap, In (F. Dignum and C. Sierra eds.) Agent-mediated Electronic commerce (The European AgentLink Perspective), LNAI 1991, pp. 1-18, 2000. [23] Wooldridge, M., Jennings, N.R., Kinny, D. (2000). The Gaia Methodology for Agent-Oriented Analysis and Design. In Int Journal of Autonomous Agents and Multi-Agent Systems, 3 (3), 2000. [24] Yu, B., Singh, M.P. (2000). A social Mechanism of Reputation Management in Electronic Communities, Cooperative Information Agents, pp.154-165, 2000
