1. Concrete examples for UC2 - Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences

This page gives information on an implementation in Protune of the rules, which are explicitly given in UC2. The Protune rules are then used to analyze their translation to the current proposal for RIF Core.

1.1. Protune

Protune (Provisional Trust Negotiation) is a trust negoatiation framework developed within REWERSE. Protune's policy language is a rule-based language, which can be used to define e.g. access control policies and credential release policies.

1.2. UC2 Rule Examples

This section implements the rules given as examples in the UC2 by using Protune's policy language and RIF Core. This is work done by Daniel Olmedilla, one of the authors of Protune, and PaulaLaviniaPatranjan.

1.2.1. Rule 1

The following rule

A buyer must provide credit card information together with delivery information (address, postal code, city, and country).

can be implemented in Protune as follows

allow(access(Resource)) :-
    valid_payment_method(C),
    valid_delivery_address(D).

valid_payment_method(C) :-
    credential(payment_card, C[type:credit_card]).

valid_delivery_address(D) :-
    declaration(delivery_address,D[address:A, postal_code:P, city:CI,      country:CO]).

The above given rules can be translated to RIF Core as:

Forall ?Resource (
  allow (access(?Resource)) :-
    Exists ?C, ?D (
      valid_payment_method(?C)
      valid_delivery_address(?D)
      )
)


Forall ?C ( 
  valid_payment_method(?C) :-
          And (
            credential(payment_card ?C)
            ?C[type -> credit_card]
          )
    )
)

Forall ?D ( 
  valid_delivery_address(?D) :-
    Exists ?A, ?P, ?CI, ?CO (
          And (
            declaration(delivery_address ?D)
            ?D[address->?A postal_code->?P city->?CI country->?CO]
          )
    )
)

Notice that here we only request the information but nothing is done with the information (e.g., charging the credit card). Doing something with the information would require the execution of actions (e.g., ask VISA if the credit card is valid) which is an important issue in Protune.

1.2.2. Rule 2

The next rule found in the UC2 is

Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.

and its implementation in Protune

allow(release(credential(C[type:credit_card]))) :-
     credential(bbb, Cred[issuer:'Better Business Bureau']).

And the RIF Core counterpart:

Forall ?C (
  allow(release(?C)) :-
     Exists ?Cred (
       And (
          credential(bbb ?Cred)
          ?Cred[issuer->'Better Business Bureau']
          ?C[type->credit_card]
       )
     )
 )

1.2.3. Rule 3

Never disclose two different credit cards to the same online shop.

At moment, Protune does not offer support for integrity constraints; one possibility to write integrity constraints in an extension of the language would be:

 :- allow(release(credential(C1[type:credit_card]))), 
allow(release(credential(C2[type:credit_card]))), C1 != C2.

Since in the current proposal for RIF there is an equality predicate but no negation, the above given rule is implemented by means of a predicate unequal that needs to be defined:

 :- Exists ?C1, ?C2 (
      And (
        allow(release(?C1))
        credential(?C1)
        ?C1[type->credit_card]
        allow(release(?C2))
        credential(?C2)
        ?C2[type->credit_card]
        unequal(?C1 ?C2)
      )
    )

1.2.4. Rule 4

The last rule given explicitly in the UC2 is

For anonymity reasons, never provide both her birth date and postal code.

Notice that the provision of information can be done in two different ways, via credentials (signed statements) or via declarations (non-signed statements). For both we need an agreement of the vocabulary used. For example, for type of credentials being credit_cards or for declarations for the request of delivery_address or billing_address. The main difference is that while credentials are currently stored and exist in advance, the declarations can be provided interactively by the user (by means of e.g. forms) what means that new knowledge could be generated when asking the user. We still have to check how integrity constraints would be applied to this. For the moment, we can assume we have a similar situation than with the credentials:

 :- allow(release(declaration(_D1[birth_date:D]))), 
allow(release(declaration(_D2[postal_code:P]))).

And a possible translation to RIF Core:

 :- Exists ?D, ?D2, ?D, ?P (
      And (
        allow(release(?D1))
        declaration(?D1)
        ?D1[birth_date->?D]
        allow(release(?D2))
        declaration(?D2)
        ?D2[postal_code->?P]
      )
    )

1.3. Commentary

Notice however, that in the implemented examples we are not showing the need for metapolicies in order to protect this policies or to protect part of those policies. This is one of the main features of Protune and would be useful to have support for it in RIF.