This is one of the possible Use Cases.
1. Abstract
A customer (or user) wants to buy a device at an eShop. The customer's and eShop's systems negotiate so as to automatically establish trust with the goal of successfully complete the transaction. The negotiation is based on the policies and the credentials each system has. The customer's and eShop's policies describe who they trust and for what purposes.
2. Status
The use case has been proposed by REWERSE to the RIF WG participants as use case 'Negotiation I: Automated trust establishment for eCommerce' and has been presented by PaulaLaviniaPatranjan at the first F2F meeting.
3. Links to Related Use Cases
Policies involved in this use case are, to some extent, similar to those in the use cases Automated Trust Establishment for Accessing Medical Records, Refund Policies in E-Commerce, and Credit Crad Transaction Authorization. For example, an alternate sequence is given in Refund Policies in E-Commerce where the use case is extended by adding action rules (e.g. for sending notifications as in the case of rule r9 in the use case described here).
4. Relationship to OWL/RDF Compatibility
5. Examples of Rule Platforms Supporting this Use Case
6. Benefits of Interchange
- Benefit 1: This use case clearly motivates the need for a rule interchange format since rules expressing policies are to be exchanged between parties engaged in negotiations.
7. Requirements on the RIF
- For negotiation, it should be able to export the policies in a format that can be understood by the other parties engaged in the negotiation.
- Different kinds of rules (deductive, normative, and reactive rules) should be supported.
8. Breakdown
8.1. Actors and their Goals
- Alice wants to buy an eShop device. She uses a system to determine if eShop is trustworthy or not.
- eShop offers products for purchase purposes.
8.2. Main Sequence
9. Narratives
Alice would like to buy online a new device at an eShop. When she clicks on buy it, the server processes the request and sends back to Alice the relevant policy. When a customer wants to buy such a device, eShop logs the requests (for marketing and statistics purposes) and discloses a policy with the following alternatives:
(r1) A gold card holder is given a 10% discount on any purchase.
(r2) An eShop employee gets 20% discount on devices of this type.
(r3) Any other buyer must provide to the shop credit card information together with delivery information (address, postal code, city, and country).
(r4) Furthermore, the credit cards accepted are VISA and MasterCard.
The policy further states that for buyers providing a valid gold card or who are eShop employees, no further interactions and verifications are needed. The policy also states in case credit card information is disclosed by a buyer, i.e. in the third of the alternatives mentioned above, still the fulfilment of some other conditions might be required and/or still the purchase request might be denied. That is because eShop uses rules such as
(r5) if the client is in the eShop client blacklist then deny purchase request;
(r6) if the client's credit card is revoked then deny purchase request.
Once Alice's negotiation system receives the eShop's policy, it checks Alice's credentials that are available (locally or from third parties) and whether some subset of these credentials fulfill the policy. Alice has a credit card but her own policy states that she is not willing to disclose it to everyone. Since Alice has never bought anything from eShop in the past, her system asks eShop to provide a proof of its membership to the Better Business Bureau (BBB), Alice's most trusted source of information on online shops. (The Better Business Bureau could be the root authority for a Public Key Infrastructures hierarchy, which can be used to establish domains of trust. E.g. Visa International could be the root authority for such a hierarchy devoted to Visa cards.) eShop has such a credential and its policy is to release it to any potential purchaser. Hence, it does so to Alice's negotiation system on its request. Alice's negotiation system is now ready to disclose her credit card information to eShop but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating
(r7) to never disclose two different credit cards to the same online shop and
(r8) for anonymity reasons never to provide both her birth date and postal code (indeed, they are a quasi-identifier).
For this purchase, anonymity is no issue and only information on one credit card is requested. Thus, Alice's constraints are respected. Alice's negotiation system therefore provides Alice's credit card information to eShop. eShop checks that Alice is not in its client black list, then confirms the purchase transaction, generates an email notification to the Alice giving information about the purchase, and notifies eShops's delivery department (r9).
10. Commentary
Automated trust establishment is possible when policies for every credential and every service can be codified; so as to minimize user intervention, the codified policies should be checked automatically whenever possible. Note that the notion of policies refers to access control policies, privacy policies, business rules, etc.
Taking into consideration the proposed classification of rules, a possible classification of the rules occurring in the given use case is:
- normative rules (r3,r4,r7,r8)
- deductive rules (r1,r2)
- reactive rules (r5,r6,r9)
However, one might argue that rules r3 and r4 are not normative but deductive rules. The above given classification is not the only possible one since the proposed classification of rules (see Classification of Rules) is un-sharp.