WO2001016835A1

WO2001016835A1 - System and method providing interoperability between enforced policies

Info

Publication number: WO2001016835A1
Application number: PCT/US2000/023407
Authority: WO
Inventors: Naftaly H. Minsky; Victoria Ungureanu
Original assignee: Rutgers, The State University Of New Jersey
Priority date: 1999-08-27
Filing date: 2000-08-25
Publication date: 2001-03-08
Also published as: AU6938400A

Abstract

The present invention relates to a method and system for providing interoperability between policies. In one aspect of the invention, a controller (22a, 22b) is assigned to each agent (24a, 24b) which are communicating with one another. The controller includes a list of policies (Lp) to which each agenter can interoperate. A message is exported from a first controller under a first law for enforcing a first policy. The message is imported at the second agent under a second law for enforcing a second policy if the message identifier to the first policy is in the list of policies to which the second agent can operate. In addition, the method of the present invention provides a secure implementation of interoperability by applying a verifiable authentication to the message before exporting the message from the first controller and the verifiable authentication is verified at the second controller. The method and system can be used to provide inter-enterprise electronic commerce, for example, in a purchase order transaction.

Description

SYSTEM AND METHOD PROVIDING INTEROPERABILITY BETWEEN ENFORCED POLICHCS

Background of the Invention

1. Field of the Invention

The present invention relates generally to coordination and control of distributed computation, and particularly to systems and methods for the specification and enforcement of access control policies and of policies for electronic commerce, including those for B2B commerce.

2. Description of the Related Art

Software technology is undergoing a transition from monolithic systems, constructed according to a single overall design, into conglomerates of semi-autonomous, heterogeneous and independently designed subsystems, constructed and managed by different organizations, with little, if any, knowledge of each other. Among the problems inherent in such conglomerates is the difficulty to control the activities of the disparate agents operating in it, and the difficulty for such agents to coordinate their activities with each other.

The nature of coordination and control required for such systems calls for the following principles to be satisfied: (1) coordination policies need to be enforced; (2) the enforcement of a policy needs to be decentralized, to allow for scalability; (3) coordination policies need to be formulated explicitly, rather than being implicit in the code of the agents involved, and the policies should be enforced by means of a generic, broad spectrum mechanism; and (4) it should be possible to deploy and enforce a policy incrementally, without exacting any cost from agents and activities not subject to it. A coordination and control mechanism that satisfies all these principles has been described by Minsky et al., in "Law-governed Interaction: A Coordination and Control Mechanism for Heterogeneous Distributed Systems," in ACM Transactions on Software Engineering and Methodology (TOSEM) October 2000, hereafter referred to as Minsky et al. This mechanism implements the concept of law-governed interaction (LGI), which is a scalable mode of message-exchange that allows a heterogeneous group of distributed agents to interact with each other, with confidence that an explicitly specified policy is strictly observed by each of its members. One of the limitations of the mechanism described in Minsky et al. is that it does not provide for interoperability between policies. But such interoperability is often desired, as is demonstrated in the following example from business-to-business (B2B) electronic-commerce.

A purchase transaction between an agent x, of an enterprise E, (the client in this case), and an agent x₂ of an enterprise E₂ (the vendor), may be subject to a conjunction of the following three policies:

• A policy P, that governs the ability of agents of enterprise E, to engage in electronic commerce. For example, policy P, may provide some of its agents with budgets, allowing an agent (a person or a program) to issue purchase orders only within the budget assigned to it.

• A policy P₂ that governs the response of agents of enterprise E₇ to purchase orders. For example, policy P₂ may require that all responses to purchase orders should be monitored, for providing internal control.

• A policy P_JJ that governs the interaction between these two enterprises, reflecting a prior contract between them. Such an " ' interaction policy" may, for example, reflect a blanket agreement between these two enterprise, that calls for agents in enterprise E₂ to honor purchase orders from agents in enterprise E, for up to a certain cumulative value, referred to as the ^" blanket" for this pair of enterprises.

The conventional approach for achieving interoperability between agents operating under different policies is to combine the policies into a single, super-policy," as described in Qian et al., "Computational Issues in Secure Interoperation," IEEE Transactions on Software Engineering, pages 43-52 (January 1996); and in Bidan et al. "Dealing with Multi-policy Security in Large Open Distributed Systems," in Proceedings of 5' European Symposium on Research in Computer Security, pages 51-66 (September 1998). In the above-described example, in particular, the three policies would be combined into a single "superpolicy." This approach has several drawbacks. First, the approach does not provide for the autonomy and the privacy of constituent sub-policies which is particularly limiting when dealing with B2B commerce between two inherently autonomous enterprises. The problem is that the creation of a super-policy requires knowledge of the text of sub-policies. However, divulging to a third party the internal business rules of an enterprise is not common practice in today's commerce. Second, interoperation by forming a composed policy requires that changes of a sub-policy be reflected in all super-policies it is part of. Accordingly, if the number of policy components is large and the individual policies are likely to change it will be cumbersome to implement maintenance of the superpolicy.

It is therefore desirable to provide a method and a system for interoperability of policies under LGI that allows for a scalable interoperation between agents operating under different policies, in a manner that preserves the privacy and the autonomy of each policy, and that provides for their mutual transparency.

Summary of the Invention The present invention relates to a method and system for providing interoperability between polices that are enforced, like under LGI. This invention allows a pair of agents operating under different policies to interact, subject to both of these policies while requiring minimal if any dependency between the policies themselves. The policy can be represented as a law governed interaction (LGI). For instance, in a scenario in which an agent x operating under an LGI policy P and an agent y operating under a different policy Q, the present invention allows agent x to send a message to agent y by exporting it to y, subject to policy P. The exported message is imported by agent y subject to its own policy Q.

The ability of agent x to export messages is governed by its policy P. In particular, policy P can impose constraints on the kind of messages that can be exported, on the target of such an export, on the policy the target operates under, and on the state of the exporter x itself. Policy P can also mandate certain changes in the state of the exporter. For example, suppose that agent x belongs to an enterprise E, and is operating under the enterprise-policy P. This policy P might allow the export of purchase-order messages of a specified form to agents operating under a policy Q governing another enterprise E₂ Policy P might allow such exports of purchase orders only if the balance in the exporter's budget is high enough, requiring that this balance be automatically reduced by the price offered in the purchase order. The ability of agent y to import messages is governed by its policy Q, in an analogous manner. For example, suppose that agent y belongs to an enterprise E_2% and is operating under the enterprise-policy Q. Policy Q might allow the import of a specified type of purchase-order messages from agents operating under policy P. In addition policy Q can include the constraint that a copy of each imported message be sent to a designated auditor object. The interoperability between pairs of policies, can be used to create combinations of more than two policies, for example the combination of three policies as shown in the above described example.

Brief Description of the Drawings

For a better understanding of the present invention, reference may be made to the accompanying drawings.

Fig. 1 is a schematic diagram of a prior art system for enforcing a law-governed interaction.

Fig. 2 is a schematic diagram of a system for interoperability between enterprises having different policies in accordance with the teachings of the present invention.

Fig. 3 is a flow diagram of a method for interoperability between enterprises having different policies.

Fig. 4A is a flow diagram of implementation of interoperability between enterprises for initiating a single purchase transaction.

Fig. 4B illustrates a flow diagram of a method for exporting messages based on the supply order forwarded in Fig. 4A.

Detailed Description

Reference will now be made in greater detail to a preferred embodiment of the invention, an example of which is illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings and the description to refer to the same or like parts. Fig. 1 illustrates a schematic diagram of a prior art system for enforcing a law-governed interaction (LGI) as described in Minsky et al., "Regulated Coordination in Open Distributed Systems," in the Proc. of Coordination'97: Second International Conference on Coordination Models and Languages; LNCS 1282; September 1997, hereby incorporated by reference into this application. A law-governed interaction (LGI) is a scalable mode of interaction that allows a heterogeneous group of distributed agents to interact with each other, with confidence that an explicitly specified set of rules of engagement, referred to as the law of the group, is strictly observed by each of its members, which are referred to as agents.

The law-governed interaction comprises policy P and is defined as a four-tuple:

{M, G, CS, L) where M is the set of messages regulated by policy P also called P-messages; G is an open and heterogeneous group of agents that exchange messages belonging to , and is referred to as a P-group; CS is a mutable set {CS_X | x e G} of control states with one per member of group G; and L is an enforced set of "rules of engagement" that regulates the exchange of messages between members of G. The law is defined over a certain type of events occurring at members of group G, mandating the effect that any such event should. The mandate is called the ruling of the law for a given event. The events thus subject to the law of a group under LGI are called regulated events. These events include the sending and arrival of P-messages, among others.

The law of a given group G is global with respect to group G, but it is defined locally at each member of it. The law is global, in that all members of group G are subject to it, the law is defined locally, at each member, in the following respects:

• The law regulates explicitly only local events at individual agents,

• The ruling of the law for an event e at agent x depends only on event e itself and on the local control-state of event x.

• The ruling of the law at a given agent x can mandate only local operations to be carried out at agent x, such as an update of the local control-state x, or the forwarding of a message from agent x to some other agent. The globality of law L of group G establishes a common set of ground rules for all members of G, providing them with the ability to trust each other, in spite of the heterogeneity of the group. The locality of the law that enables its scalable enforcement, by means of a trusted agent called a controller which is associated with individual members of group G.

The law L of a group is a function that returns a ruling for every possible regulated-event that might happen at a given agent. The ruling returned by the law is a possibly empty sequence of primitive operations, which is to be carried out in response to the event in question, at its home. An empty ruling implies that the event in question has no consequences, such an event is effectively ignored. Prolog-like language is used to specify laws. Members of a P-group are referred to as agents so as to represent autonomous actors that can interact with each other, and with their environment. An agent can be an encapsulated software entity, with its own state and thread of control, or it might be a human that interacts with the system via some interface. An agent does not imply either "intelligence" or mobility, although the agents can have these characteristics. Members of a given P-group are viewed as sources of messages and targets for them.

The control-state CS_X of a given agent x associates various attributes with this agent. For example, these attributes can be represented as a bag of Prolog-like terms. The attributes are used to structure group G and provide state information about individual agents, thereby allowing law L to make distinctions between different members of the group. The control-state CS_x can be acted on by primitive operations, as described below, subject to law L.

The events that are subject to the law L of a policy are referred to as regulated events. Each of the events occurs at an agent, referred to as the home of the event. The following are two examples of event-types. 1. sent(x, m, y) - occurs when agent x sends a message m under law L addressed to agent y. The sender x is considered the home of this event.

2. arrived(x, m, y) - occurs when a message m under law L sent by agent x arrives at agent y. The receiver^ is considered the home of this event.

Operations included in the ruling of law L for a given regulated event e, to be carried out at the home of this event, are called primitive operations. Primitive operators include operations that update the control-state of the home agent and operations on messages. Primitive operations on the control-state of the home agent include: (1) +t, which adds the term t to the control state; (2) -t, which removes a term t from the control-state; (3) tl — 12, which replaces term tl with term t2 in the control-state; (4) incr(t(v),d), which increments the value of the parameter v of a term t with quantity d in the control-state, v and d can be assumed to be integers; and (5) dcr(t(v),d), which decrements the value v of a term t with quantity d in the control-state.

Primitive operations on messages include operation forward (x, m, y) and operation deliver (x, m, y). Operation forward (x, m, y) sends message m to agent y, where x identifies agent x as the sender of the message. The receipt of the message triggers at agent y an arrived (x, m, y) event. Operation deliver (x, m, y) delivers the message m to the home-agent y, where x is the nominal sender of this message. The receipt of the message from the operation deliver at agent y does not trigger any event.

As shown in Fig. 1, Law L is enforced by a set of controllers 12a-12d which are trusted entities that mediate the exchange of messages under policy P between agents 14a-14d. Agents 14a-14d are members of group G. A controller 12a-12d is logically placed between every active member represented by agents 14a-14d and communications medium 16. Controllers 12a-12d have identical copies of law L of policy P, and each of controllers 12a-12d maintains the control-state, CS, of agents 14a-14d under its jurisdiction. This allows the controller C_x assigned to agent x to compute the ruling of law L for every regulated event at agent x, and to carry out this ruling locally.

Controllers 12a-12d are generic, and can interpret and enforce any well-formed law. A controller operates as an independent process, and it can be placed on the same machine as its client, or on another machine, located anywhere in the communications medium 16. Each controller can serve several agents, operating under possibly different laws. This facilitates various optimization techniques, as discussed in Minsky et al.

Policy P is supported by server 18, called the secretary of policy P, and is denoted by S_p Secretary S_p maintains the law L of policy P and the membership of G and it acts as a name server for group G. For example, for agent x to be able to exchange messages under policy P, it needs to engage in a connection protocol 19 with server Sp 18. Connection protocol 19 assigns agent x 14a to controller 12a. Controller 12a is provided with law L_p of policy P and the initial control state of x, CS_X. The following scenario relates to a pair of agents x and y that have joined a group G of a policy P. Agent x 14a and agent y 14b are respectively assigned to controller C_x 12a and controller C_y 12b operating under law L_p. Thereafter if agent x 14a wants to send a message m to agent y 14b, agent x sends message m to controller C_x 12a. When message m arrives at controller C_x 12a, it triggers a sent (x, m, y) event. When controller C_x 12a picks up this event, it evaluates the ruling of law L_p for it, with respect to control-state CS_X that it maintains, and carries out this ruling. If the ruling calls for the control-state CS_X to be updated, such update is carried out directly by controller C_X 12a. If the ruling for event sent (x, m, y) calls for message m to be forwarded to agent y, then controller C_x 12a sends message m to controller C_y 12b. If controller C_x 12a does not have the address of controller C_y 12b, controller C_x 12a prompts server S_p 18. When server S_p 18 responds, controller C_x 12a forwards message m to controller C_y 12b and controller C_x 12a caches the address of controller C_y 12b. When message m arrives at controller C_y 12b it triggers an arrived (x, m, y) event. Controller C_y 12b evaluates and carries out the ruling of the law for this event. For example, this ruling can call for a message m to be delivered to agent y 14b, and for the control-state CS_y maintained by controller C_y 12b to be modified.

In general, all regulated events that occur nominally at agents 14a-14d actually occur at their respective controller 12a-12d. To avoid race conditions, the events pertaining x 14a are handled sequentially in chronological order of their arrival as follows: controller 12a evaluates the ruling of the law for each event and atomically carries out this ruling, thereby the sequence of operations that constitute the ruling for one event do not interleave with those of any other event occurring at agent x 14a.

For the above-described mechanism to be effective the following assurances are needed: (a) that the exchange of P-messages is mediated by controllers operating under the same policy P, and thus interpreting the same law L of this policy; and (b) that all of the controllers are correctly implemented. If these two conditions are satisfied, then it follows that if agent y receives a P-message from some agent x, this message must have been sent under the same law of policy P. These assurances are provided by the controller-to-controller interaction protocol of LGI, whose essence is described below. Regarding the first of the above concerns, each controller uses an identifier id(P) for the policy it operates under, which comprises the pair (Sp hash(law(P)), address of S_p). In an alternate embodiment one of the identifiers in the pair can be omitted. In order to ensure that a message forwarded by controller C_x under policy P would be handled by C_y under the same policy, C_x appends its id(P) to the message it forwards to C_y. Controller y would accept this as a valid P-message only if id(P) is identical to its own. Conventional cryptographic techniques can be used to ensure that messages are securely transmitted over the network.

Regarding the second assurance described above related to correctness of the controllers, when a user is not concerned with malicious violations, the controller software can be trusted in a manner similar to that of various known tools on the internet, such as the e-mail software or browsers. Alternatively, when malicious violations are a concern, the validity of controllers, and of the host on which they operate, is certified by a certifying authority for controllers, called a "controller-server". These certificates are exchanged between controllers during their first hand-shake.

It is appreciated that the authenticity of controllers depends here on the assumption that their private key is not disclosed. A confidence in this assumption can be enhanced by placing each controller on securely maintained hosts, or by building the controller into conventional physically secure coprocessors which devices are protected by sensing circuitry which erases non-volatile memory before attackers can penetrate far enough to disable the sensors or read memory contents.

Fig. 2 is a schematic diagram of a system for interoperability between different policies 20 in accordance with the teachings of the present invention. The term "interoperability" between a pair of different policies P and Q is defined as the ability of an agent x/P, representing an agent x operating under policy P, to exchange messages with y/Q, representing an agent v operating under policy Q, such that the following properties are satisfied.

• Consensus: An exchange between a pair of policies is possible only if it is authorized by both. • Autonomy: The effect that an exchange between x/P and y/Q may have on the structure and behavior of agents x/P and y/Q is subject to policies P and Q respectively.

• Transparency: Interoperating parties need not to be aware of the details of each other policy.

Controller C_x 22a is placed between agent x/P 24a and communication medium 26. Controller C_x 22a operates under policy P. Controller Cy 22b is placed between agent y/Q 24b and communication medium 26. Controller C_y 22b operates under policy Q. Controller C_x 22a communicates with server S_p 28a. Controller C_y 22b communicates with server S_p' 28b. Server S_p 28a includes the function of secretary as described above for server 18, and is extended to operate as a name server for policies that interoperate with policy P. For example, server S_p, 28a maintains a list of policies P ' to which members of P are allowed to export to and respectively import from subject to law L_p. For each policy P ', server S_p 28a records among other information the address of server S_p 28b. Server S_p 28b has similar functionality as server S_p 28a. Connection protocol 29 connects server S_p 28a and server S_p 28b to respective controller C_x 22a and controller C_y 22b; this protocol is essentially the same as protocol 19 of the prior art realization of LGI (see Fig. 1) with different features that, if a controller C_x 22a is assigned to a member in a policy P, then this controller maintains a list of the policies P ' which inter-operates with P. For every policy P ' in the list, controller C_x 22a records an identifier \ά(P), defined as we have seen before. This information is given to controller 22a by server S_p 28a at the time agent x 24a is assigned to controller C_x 22a. A similar connection protocol 29 is used in controller C_y 22b.

An interoperability primitive operation provides an initialization of an exchange of messages between agent x/P 24a and agent y/Q 24b. The interoperability primitive operation is represented by operation export (x/P, m, y/Q) operating under policy P invoked by agent x to initiate an exchange between agent x/P 24a and agent y/Q 24b operating under policy Q. When the message carrying this exchange arrives at agent y/Q 24b, an imported event is invoked under Q. The imported event is represented by event imported (x/P, m, y/Q). Fig. 3 is a flow diagram of an implementation of a method for providing interoperability between different policies using system 20. Consider an agent x/P 24a operating under policy P, and suppose that some event occurs at its controller C_x 22a) whose ruling, by policy P, is to export a message m to agent y/Q 24b, as shown in block 31. If controller C_x 22a does not already have the address of controller C_y 24b, controller C_x 24a sends a request for the address of controller C_y 24b to server S_p' 28b, in block 32. When server S_p' 28b responds, controller C_x 22a will cache the address of controller C_y 24b.

In block 33, the export of message from controller C_x 24a to controller C_y 24b is performed. A controller-to-controller interaction protocol can be used in this step, which differs from the analogous protocol used by LGI for interaction under the same policy in that the policies under which C_x 24a and C_y 24b operate are not identical, and neither are their identifiers. In block 34, controller C_y 22b evaluates the ruling of its law for its import and carries out its ruling.

In general system 20 satisfies the desired conditions of consensus, autonomy, and transparency, described above. First, the consensus condition stipulated that interoperation between a pair of agents under two different policies should be authorized by both policies. This condition is satisfied because for an agent under policy P to communicate to an agent under a different policy Q, policy P must have a rule that invokes an export operation to policy Q and policy Q must have a rule that responds to the resulting imported event from policy P. Second, the autonomy condition, which stipulates that the effect that an exchange initiated by agent x/P may have on the structure and behavior of agent y/Q, should be subject to policy Q alone, is satisfied since the effect on agent y/Q of an import of a message from elsewhere is determined by the ruling of the law of policy Q concerning "imported" events. Finally, the transparency condition, which stipulates that interoperating parties need not to be aware of the details of each others policy, is satisfied since when an agent y/Q handles a message exported from agent x/P, it has access only to the message itself and to the address of its source, but not to the policy P under which it has been produced.

The following is an example of how the three policies Pi, P₂ and Pj described in the background of the invention can be made to interoperate to allow for regulated B2B transactions. After the presentation of the three policies, the manner in which they interoperate using system 20 is illustrated by describing the progression of a single purchase transaction. Policy Pi governs the ability of agents within an enterprise Ei to issue purchase orders. Specifically, Pi requires that for an agent c, representing a client in enterprise E], to issue a purchase order (PO) for price p, it must have a budget assigned to it, with a balance not smaller than p. Once a PO is issued, the agent's budget is reduced accordingly. If the purchase order is declined then the client's budget is to be restored.

The set of Py-messages subject to this policy comprise the following:

• purchaseOrder (specs, p,c), which denotes a purchase order for a merchandise described by specs, and for which the client c is willing to pay a price p.

• supplyOrder (specs, ticket), which represents a positive response to a purchase order for the specified merchandise, where ticket represents the requested merchandise.

• declineOrder (specs, p, reason), which denotes a rejection of a PO for the specified merchandise. This rejection returns any currency for price p offered in the PO, and contains the reason for the rejection.

The control-state of each member in this policy contains a term budget(val), where val is the value of the budget. The law of policy Pi is presented in Table 1, and it consists of three rules. Under this law members are allowed to export to and import from members of policy P , described later. The language used to define laws for LGI is described in detail in Minsky et al. Each rule is followed by an informal explanation in italics.

Table 1

Rl. sent(Xl, purchaseOrder(Specs,Price,Xl),X2):- budget(Val)@CS, Val>Price, do(dcr(budget(Val),Price)). do(export(Xl/Pι,purchaseOrder(Specs,Price,Xl),X2/ Pι,₂)).

In Rule Rl purchaseOrder message is exported to the vendor X2 that operates under the inter-enterprise policy P;,₂ if Price, the amount XI is willing to pay for the merchandise is less than val.

R2 imported(X2/ P ,supplyOrder(Specs,Ticket),Xl/ Pι) do(deliver(X2,supplyOrder(Specs,Ticket),Xl)).

In Rule R2, a supplyOrder message, imported from /Pi, 2 is delivered.

R3 imported(X2//Pi_>2,declineOrder(Specs,Price,Reason),Xl/ Pi):- do(incr(budget(Val),Price)), do(deliver(X2,declineOrder(Specs,Price,Reason),Xl)).

In Rule R3 a declineOrder message, imported from policy Pi, ₂, is delivered after the budget is restored by incrementing it with the price of the failed PO.

Policy P₂, which governs the response of agents of enterprise E₂ to purchase orders, requires that all purchase orders and all responses to them be monitored by a designated agent called "auditor". Unlike policy Pi which allows for interoperability only with policy Py,₂ the law of policy P₂ allows for interoperability with arbitrary policies to allow for interoperability between groups of policies. The law of policy P₂ is displayed in Table 2. In this embodiment the set of messages recognized by policy P₂ is the same as for policy Pi. In alternate embodiments the set of messages between policy Py and policy P₂ can be different. Table 2

Rl. imported(I/IP,purchaseOrder(Specs,Price,Xl),X2/ P₂) do(+order(Specs,I,IP)), do(deliver(X2, purchaseOrder(specs,Price,Xl),auditor)), do(deliver(X2, purchaseOrder(Specs,Price),X2)).

In Rule Rl, when a purchaseOrder is imported by vendor X2, the message is delivered to the intended destination and also to the designated auditor.

R2 sent(X2,M,Xl):-

(M=declineOrder(Specs,Price,Reason)|M=supplyOrder(Specs,Ticket)), order(Specs,I,IP)@CS,do(-order(Specs,I,IP)), do(export(X2/ P₂,M,I/IP)), do(deliver(X2,M,auditor)).

In Rule R2, a message sent by the vendor is delivered to the auditor. The message is exported to I, the interactant from which this order originally came, under an interaction policy IP. For example, I can be an object blanket operating under policy P .

Policy Pι,₂ , which governs purchasing interactions between agents in enterprise Ei and agents in enterprise E₂, represents a blanket agreement between the two enterprises. Specifically, this policy requires that a purchase order be processed by the vendor only if the amount offered by the client does not exceed the remaining balance in the blanket. The group of agents subject to this policy consists of the set of agents from the vendor-enterprise £₂ that may serve purchase orders, and a distinguished agent, referred to as the blanket agent that maintains the balance for the purchases of the client- enterprise Ei. The law Ly,₂ of policy P;,₂ is defined in Table 3. Table 3

Initially: Agent blanket has in its control state a term of the form balancefval), where val denotes the remaining amount of money that the agent of enterprise E] has available to purchases, at a given moment in time.

Rl. imported(Xl/Pι,purchaseOrder(Specs,Price),X2/ Pι,₂):- do(forward(X2,purchaseOrder(Specs,Price,Xl), blanket). In Rule Rl, a purchaseOrder message imported by a vendor X2 is forwarded to blanket or approval.

Rl. arrived(X2,purchaseOrder(Specs,Price,Xl , blanket) :- balance(Val)@CS, Val>=Price, do(dcr(balance(Val),Price)), do(order(Specs,Price,Xl,X2)), do(export(blanket/ Pι_?2> purchaseOrder(Specs,Price,Xl),X2/ P₂)). In Rule R2, if Price, the sum XI is willing to pay for the merchandise, is less than Val the value of the balance, then the purchaseOrder message is exported to X2, the vendor which originally received the request under policy P₂.

R3. arrived(X2,purchaseOrder(Specs,Price,Xl),blanket):- balance(balance(Val)@CS,Val<Price, do(export(X2/ Pι,2, declineOrder(Specs,Price,"insuffιcient funds"),Xl/ P ). In rule R3, if the balance is less than the Price then a declineOrder message is exported to XI, the client which originally issued the purchaseOrder.

R4. imported(X2/ P₂,declineOrder(Specs,Price,Reason),blanket/ P^):- do(incr(balance(Amount),Price), order(Specs,Price,Xl,X2)@CS, do(-order(Specs,Price,Xl,X2)), do(export(X2/ Pi, 2, declineOrder(Specs,Price,Reason),Xl/ Pi)).

In Rule R4, if the vendor cannot honor the order, the client-enterprise has its blanket increased by Price. Also the message is exported to XI the individual client which issued the request. R5. imported(X2/ P₂,supplyOrder(Specs,Ticket),blanket/ P^):- order(Specs,Price,C,X2)@CS, do(-order(Specs,Price,Xl,X2)), do(export(X2/ Pι,2, supply(Specs icket), Xl/ Pi)). In Rule R5, a supplyOrder message is exported to the client XI which issued the order.

Note that policy Pi and policy P₂ do not depend on each other in any way. Each of these policies provides for export to, and import from, the interaction policy Pι,₂ but the policies have no dependency on the internal structure of P_J .

Referring to Fig. 4A and Fig. 4B, it is illustrated how the above-described policies function together, by means of a step-by-step description of the progression of a single purchasing transaction initiated by a purchase order (PO) sent by agent xi/Pi (i.e., agent x; operating under policy Pi) of an enterprise Ei (the client) to an agent x₂/P₂ of enterprise E₂ (the vendor).

Referring to block 41 of Fig. 4A, a PO sent by agent x/P; to agent x₂/P₂ is handled under rule Rl of policy Pi. If the budget of agent xi/Pi is smaller than the specified price, then the PO is ignored. If the budget of agent x Pi is greater than or equal to the specified price the following operations are carried out: (a) the budget of agent x/P; is decremented by the specified price; and (b) the PO is exported to agent x₂/P;.₂.

In block 42, the import of a PO by agent x₂/P;,₂ (a vendor operating under P_J ) activates the forwarding of this PO to the blanket agent, under policy Py ? (see rule R; of policy Pi, 2)- The agent blanket, which operates under policy Pι,2, and has in its control-state the term balance(V), where V represents the remaining balance under the blanket agreement between the two enterprises. The arrival of a PO, at the blanket agent causes a balance of the blanket to be compared with the price of the PO, as shown in block 43. If the balance of the blanket is bigger than the price of PO, the balance of the blanket is decremented by this price, and PO is exported to the vendor agent x₂/P under Rule R2 of policy Pi, 2 , in block 44a. Alternatively, if the balance is smaller than the price, a declineOrder message is exported back to agent xy/Py under Rule R3 of policy Pi, in block 44b.

Fig. 4B describes the treatment of a PO once it is exported to x₂/P₂. In block 45, the PO is imported by x₂/P₂, and is immediately delivered to two agents: (a) to the vendor agent x₂/P₂ itself, for its disposition; and (b) to the agent auditor, designated to maintain the audit trail for all purchase orders received by vendors, and for the responses of the vendors to these orders.

In block 46, agent x₂/P₂ that received a PO can respond by sending one of two kinds of messages to agent xy/Py that originated the PO: a supplyOrder message, or a declineOrder message. In block 47, the sending of either of these messages triggers two operations under Rule R2 of policy P₂: (a) the message is exported to blanket, operating under policy policy Pj,₂, and (b) a copy of this message is delivered to the auditor agent, under policy P₂.

In block 48, it is determined if the import of the response of agent x₂/P₂ by the agent blanket, operating under policy Py,₂ is a supplyOrder or a declineOrder message. If the response is a supplyOrder message, then this message is automatically exported to the agent xy/Py under Rule R5 of policy Py,₂ in block 49a. If the response is a declineOrder message, then the blanket balance is incremented by the price amount it had been previously decremented, and the declineOrder message is exported to the agent xy/Py under Rule R4 of policy Py,₂ in block 49b.

In block 50a, the import of a supplyOrder message into agent xy/Py causes this message to be delivered to agent xy/Py under Rule R2 of policy Py. In block 50b, the import of a declineOrder message into xy/Py causes the budget of agent xy/Py to be restored, before the message is delivered to it under Rule R3 of policy Py.

It is understood that the above-described embodiments are illustrative of only a few of the many possible specific embodiments which can represent applications of the principles of the invention. Numerous and varied other arrangements can be readily derived in accordance with these principles by those skilled in the art without departing from the spirit and scope of the invention.

Claims

What is claimed is:

1. A method of providing interoperability between a first agent operating under a first policy and a second agent operating under a second policy comprising the steps of: assigning a first controller to said first agent, said first controller accessing a first list of policies to which said first agent can interoperate; assigning a second controller to said second agent, said second controller accessing a second list of policies to which said second agent can interoperate; exporting a message from said first agent to said second agent by said first controller under a first law for enforcing said first policy, said message including an identifier to said first policy; and importing said message at said second agent under a second law for enforcing said second policy if said identifier to said first policy of said message is in said list of policies to which said second agent can interoperate.

2. The method of claim 1 further comprising the steps of: applying a verifiable authentication to said message before exporting said message, said verifiable authentication indicating said first controller is an authentic controller with a trusted authority; and verifying said verifiable authentication in said step of importing said message at said second agent.

3. The method of claim 2 wherein said verifiable authentication is a public key and a signature.

4. The method of claim 3 wherein said signature includes said message, a hash of said first law and a hash of said second law.

5. The method of claim 1 wherein said first policy and said second policy are defined by a four-tuple of

{M, G, CS, L) where M is a set of messages regulated by policy P; G is a group of agents that exchange messages belonging to ; CS is a mutable set of control states with one said control state per member of group G; and L is a law comprising an enforced set of rules of engagement for regulating the exchange of said set of messages between members of said group G.

6. The method of claim 5 wherein said step of exporting said message from said first agent is performed by a rule of said first law involving an operation export (X/P,m,y/Q) wherein x represents said first agent, y represents said second agent, P represents said first policy and Q represents said second policy.

7. The method of claim 6 wherein said step of importing said message at said second agent is performed by a rule of said second law responding to an event (X/P,m, Y/Q) occurring when said message arrives at said second agent.

8. The method of claim 7 further comprising the step of: evaluating said import event with said second law and said control state of said second agent.

9. The method of claim 1 wherein said first agent is a first business enterprise and said second agent is a second business enterprise.

10. The method of claim 1 further comprising the step of: defining an interaction policy for interaction between said first agent and said second agent wherein said first agent operates under said first policy and said interaction policy and said second agent operates under said second policy and said interaction policy.

11. A method of providing interoperability between a first agent operating under a first policy and a second agent operating under a second policy in a purchase transaction comprising the steps of: handling a purchase order from a first agent assigned to a first controller to a second agent assigned to a second controller under a first policy that if a first agent budget is smaller than a price of said purchase order, said purchase order is ignored and if said first agent budget is greater than said price of said purchase order, said purchase order is exported from said first controller assigned to said first agent to said second controller assigned to said second agent and said first agent budget is decremented by said price of said purchase order; forwarding said purchase order from said second controller to an agent blanket, said agent blanket operating under an interaction policy to determine if said price of said purchase order is less than a budgeted price agreed to in said interaction policy and if said price of said purchase order is less than a balance of said agent blanket; and either issuing a first supply order message at said second agent if said price of said purchase order is less than said balance of said agent blanket and reducing said balance of said agent blanket by said price of said purchase order and sending said second agent said purchase order; or issuing a first decline order message to said second agent if said price of said purchase order is greater than said balance of said blanket agent.

12. The method of claim 11 wherein after said step of issuing a supply order message further comprising the steps of: importing said purchase order under said second policy from said second controller to said second agent; and responding to said purchase order at said second controller assigned to said second agent under said interaction policy with either issuing a second supply order message at said second agent or issuing a decline order message at said second agent.

13. The method of claim 12 wherein after said step of issuing a supply order message comprising the step of: exporting said second supply order message to said first controller of said first agent

14. The method of claim 12 wherein after said step of issuing a decline order message further comprising the step of: incrementing said balance of said agent blanket by said price of said purchase order and exporting said second decline order message to said first agent.

15. The method of claim 12 wherein in said step of importing said purchase order said purchase order is forwarded to an auditor agent.

16. A system for providing interoperability between a first agent operating under a first policy and a second agent operating under a second policy comprising: a first controller assigned to said first agent, said first controller accessing a first list of policies to which said first agent can interoperate; a second controller assigned to said second agent, said second controller accessing a second list of policies to which said second agent can interoperate; means for exporting a message from said first agent to said second agent by said first controller under a first law for enforcing said first policy, said message including an identifier to said first policy; and means for importing said message at said second agent under a second law for enforcing said second policy if said identifier to said first policy of said message is in said list of policies to which said second agent can interoperate.

17. The system of claim 16 further comprising: a verifiable authentication being applied to said message before exporting said message, said verifiable authentication indicating said first controller is an authentic controller with a trusted authority; and means for verifying said verifiable authentication during importing said message at said second agent.

18. The system of claim 17 wherein said verifiable authentication is a public key and a signature.

19. The system of claim 18 wherein said signature includes said message, a hash of said first law and a hash of said second law.

20. The system of claim 16 wherein said first agent is a first business enterprise and said second agent is a second business enterprise.