This is an archive of an inactive wiki and cannot be modified.

1. Abstract

This is a synthesis of the RIF use cases falling in the category Policy-Based Transaction Authorization and Access Control.

2. Status

3. Links to Related Use Cases


4. Relationship to OWL/RDF Compatibility

5. Examples of Rule Platforms Supporting this Use Case

6. Benefits of Interchange

7. Requirements on the RIF

The different use cases falling into this class (Policy-Based Transaction Authorization and Access Control) show a number of different application scenarios that share the following common technical features:

1. Decision rules

That is, rules of the form A :- B1 and B2 and ... Bn (n greater than or equal to 0). These rules specify decisions (when the head is, for instance, allow(John, read, paper.pdf) or giveDiscount(percent50,Mary)) and so-called "abbreviations", i.e. auxiliary concepts (e.g., when the head is authenticatedUser(Ann) or acceptedCreditCard(VISA)).

All use cases comprise decision rules; Trust negotiation use cases mention abbreviation rules.

2. Integrity constraints (ICs)

Certain combinations of facts are to be forbidden, e.g. giveDiscount(percent50,Mary) and giveDiscount(percent30,Mary), because some predicate is intended to satisfy some functional dependency. In the Trust Negotiation use cases, ICs are used to prevent the release of certain sets of credentials (e.g. because they are too sensitive).

See use cases: Price Discounting, Refund Policies in E-Commerce, Supply Chain Ordering Lead Time, Automated Trust Establishment for eCommerce

3. Priorities and preferences

Priorities are necessary to resolve conflicts between different rules, either from one peer or from several of them. Preferences are needed to decide - among the alternative sets of facts to be exchanged during a negotiation - which alternative should be chosen.

See use cases: Price Discounting, Refund Policies in E-Commerce (found also in [6]), Supply Chain Ordering Lead Time. Preferences should be included in Automated Trust Establishment for eCommerce.

4. Deduction and abduction

When all the relevant facts are available and a decision can be made, rules are used to infer decisions (see point 1). During negotiation, rules are used in an abductive fashion to identify the alternative sets of facts that can make the negotiation succeed (i.e. the facts that together with the rules entail a desired decision atom).

The use cases on Automated Trust Establishment involve abduction.

5. Strong negation

In several use cases, rule heads are negated. This is another possible source of conflicts between rules, that can be solved via priorities. The same final effect could be obtained by crafting rules in a different way but "users tend spontaneously to specify policies incrementally by means of exceptions". Strong negation allows to do the same in the formal language, thereby making the formalism more user-friendly.

The use case involving strong negation is Credit Card Transaction Authorization.

6. Further features arising from future use case refinements

Most use cases suggest that some base predicates (defined by facts) are actually computed by calls to external code. This is made explicit in several papers on trust negotiation [1-3].

In multi-party negotiations, atoms may be prefixed with the peer that has to supply them (distributed logic programs, or modal extensions). Rules may be cryptographically signed to certify their authenticity [4].

Negation as failure is frequently used for incremental policy formulation, much like strong negation+priorities [5].

"Provisional policies" involve action execution (logging, notifications, etc.). Technically, they are being tackled by associating procedural actions to body literals [3] and by adopting active rules.

8. Breakdown (abstract view)

This part offers an abstract overview on actors (and their goals) and main sequences of the use cases in this category. Detailed examples of use cases are given in the next section.

8.1. Actors and their Goals

8.2. Main Sequence(s)

9. Narratives (or detailed use cases)

Concrete examples corresponding to the main sequences (e.g. in which transactions ought to be authorized and disallowed, respectively, or for determining the discount refund percentages) are given.

This part gives two detailed use cases falling in this use cases' category.

9.1. Use Case 1: Credit Card Transaction Authorization

This narrative is based on the use case Credit Card Transaction Authorization (by BenjaminGrosof).

9.1.1. Description

This use case describes an example of authorization in e-commerce: authorization by a merchant of credit card transactions requested by customers.

The merchant ("eSellWow") merges the authorization policies of credit card issuer (called the "bank") with the merchant's own additional authorization policies.

Policies of the bank

The following group of rules are policies of the bank, then adopted/imported as a group/module by the merchant, in this case eSellWow.

Rules have different priorities.

Policies of the merchant

The following group of rules are additional policies of the merchant eSellWow, which are adopted/imported from a vendor and consultant when setting up its e-store Web site.

Rules have different priorities.

Additional rules (known to the merchant and the bank)

The following are additional background fact rules, known to the merchant eSellWow and the bank.

Additional rules known to the merchant

The following are additional background fact rules, known to the merchant eSellWow.

9.1.2. Scenarios

The following groups of "case" facts each specify a particular case scenario of a requested customer transaction.

Joe Goya has a card in good standing, unexpired, and the transaction amount is below the account limit. His customer rating is good. Transaction expiration date, address, and CVC are unavailable, as is fraud alert rating. The policies thus imply that his transaction ought to be authorized by the merchant as well as by the bank.

Mary Freund has a card in good standing, unexpired, and the transaction amount is below the account limit. Her address matches, and her fraud report and customer rating are fine. But the transaction CVC and address do not match the ones on file. Thus the policies imply that the transaction on her card ought to be disallowed by the merchant as well as the bank.

Andy Lee has a card in good standing, unexpired, and the transaction amount is under the account limit. But his customer rating is bad. Thus the policies imply that his transaction ought to be disallowed by the merchant (regardless of whether the bank allows it).

The entailed approval vs. denial by the bank, and by the merchant, of authorization of the requested credit card transactions is based on the policy rules, their priorities and the casual facts. The rules and facts are given in Credit Card Transaction Authorization by using the RuleML/SWSL presentation syntax for CLP (Courteous Logic Programs).

9.2. Use Case 2: Automated Trust Establishment for eCommerce

This narrative is based on the use case Automated Trust Establishment for eCommerce.

9.2.1. Description

Alice wants to buy a device at an eShop. Alice'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. Alice's and eShop's policies describe who they trust and for what purposes.

When Alice clicks on buy it at the eSho's Web site, 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:

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

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

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.

9.2.2. Comments on Interoperability vs. Interchange



10. Commentary

This part gives a couple of references for further reading.

[1] P. Bonatti, P. Samarati. A Uniform Framework for Regulating Service Access and Information Release on the Web. Journal of Computer Security, 10(3):242-272, 2002.

[2] Kent E. Seamons, Marianne Winslett, Ting Yu, Bryan Smith, Evan Child, Jared Jacobson, Hyrum Mills, Lina Yu: Requirements for Policy Languages for Trust Negotiation. POLICY 2002: 68-79

[3] P.A. Bonatti, D. Olmedilla. Driving and monitoring provisional trust negotiation with metapolicies. IEEE 6th International Workshop on Policies for Distributed Systems and Networks (POLICY 2005), 14-23

[4] Rita Gavriloaie, Wolfgang Nejdl, Daniel Olmedilla, Kent E. Seamons, Marianne Winslett: No Registration Needed: How to Use Declarative Policies and Negotiation to Access Sensitive Resources on the Semantic Web. ESWS 2004: 342-356

[5] P.A. Bonatti, P. Samarati. Logics for authorizations and security. In J. Chomicki, R. van der Meyden, G. Saake (eds.) Logics for Emerging Applications of Databases, Springer-Verlag, August 2003.

[6] Benjamin Grosof, Chitravanu Neogy, Shashidhara Ganjugunte. Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules. Available at: .

[7] Benjamin Grosof. DIPLOMAT: Compiling Prioritized Default Rules Into Ordinary Logic Programs, for Electronic Commerce Applications (Extended Abstract of Intelligent Systems Demonstration). Available at