This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of the RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.
Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.
Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.
Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the two systems.
When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:
A buyer must provide credit card information together with delivery information (address, postal code, city, and country).
Rules express compactly possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In our example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials to disclose. Note, however, that this is a deliberately simplified example in which credentials' requests can be handled more directly.
For determining whether Venditor's request for information is consistent with Alice's policy, Emptor takes its rules into account, which state for example:
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:
Never disclose two different credit cards to the same online shop.
For anonymity reasons, never provide both her birth date and postal code.
Different choices exist for implementing the above constraints as rules; choosing the type of rules for implementing policies depends also on the capabilities of the Emptor system.
For this purchase, anonymity is no issue and only information on one credit card is requested. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor. Venditor checks that Alice is not on eShop's blacklist, then confirms the purchase transaction.
Companies that provide software such as Venditor and Emptor would make use of the RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clients they would use the RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses the RIF. Emptor takes that policy and translates it from the RIF to its internal representation in order to determine what it needs to do.
Motivates:
The rule systems employed by the agents involved in a negotiation, Emptor and Venditor here, might have different capabilities. Thus, situations may occur where an agent does not understand (part of) the rules received from the other agent, even though they were interchanged through RIF. In such cases, a way to specify the default behavior would at least ease the understanding of the reasons why the negotiation failed or entailed just partial results, such as access to part of the data or services.
Because of the rich diversity of agents in the setting of automatically establishing trust through negotiations, a limited number of RIF dialects would decrease the number of negotiations that failed because of incompatible dialects.
Intuitively, it is clear that RIF should cover features found in most of the existing policy languages. A more detailed discussion on the rule language coverage follows.
Syn 1.7 Means to access data in Web formats
Policies frequently contain simple ontologies; means to access and reason with OWL data is needed for applications involving such policies.
SeS 2.9 Priority
A conflict resolution mechanism is needed e.g. in situations where different policies may apply; prioritizing policies would be useful in such cases.
ECA 5.1 General
Policies may need support for event detection, event communication, and execution of actions; thus, support for reactive behaviour is needed.
ECA 5.4 Actions
Different kinds of actions are needed, such as updates to data, sending events, procedural attachments, etc.
Types 6
Support for datatypes is needed; the kinds of datatypes depend on the considered application.
The dialect specification of the interchanged rules together with information on the compatibility between the (standard) RIF dialects used by the parties, which need to establish trust by interchanging rules, can be used in this setting for deciding to continue the negotiation or not. Incompatible (standard) RIF dialects do not support the negotiation of the parties involved.
Often, agent softwares need to adopt existing policies, such as rules regulating some application domain, which might be written in other rule languages than the one used by the agent. In such cases, these existing policies need to be merged with agent's own policies, i.e. there is a need for merging rule sets.
Concrete examples given in Protune