1. Abstract
This is a synthesis of the RIF use cases falling in the category Policy-Based Transaction Authorization and Access Control.
2. Status
Editors of this analysis: PaulaLaviniaPatranjan and PieroBonatti
Based on 4 use cases submitted by BenjaminGrosof, 2 use cases submitted by REWERSE, and one submitted by MinsuJang
- Further requirements on the RIF might arise from more detailed versions of some of the use cases in this category.
3. Links to Related Use Cases
![/!\](https://www.w3.org/2007/04/wiki/modern-static/img/alert.png "/!\"){kind=small}
4. Relationship to OWL/RDF Compatibility
Policies can be described in factual format a la RDF or OWL, while more complex ones are written as rules. An example of a policy specification language grounded in OWL is Rei.
The need arises for mixing data expressed in different formalisms so as to perform inferencing (see use case Policy - Preference Computing).
5. Examples of Rule Platforms Supporting this Use Case
Use cases Credit Card Transaction Authorization, Refund Policies in E-Commerce, Price Discounting, Supply Chain Ordering Lead Time have been implemented in SweetRules V2 (and in earlier form, in IBM CommonRules).
Support for use cases Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records: The current prototype called PeerTrust supports distributed, multi-party credential negotiation, with real networking and real X.509 credentials. Interested people are referred to the site PeerTrust (contact person Daniel Olmedilla <olmedilla@l3s.de>).
Support for use case Policy - Preference Computing: Rule systems with OWL/RDF processing capabilities, such as Euler, Bossam, KAON2, and Hoolet.
6. Benefits of Interchange
- These use cases clearly motivate the need for a rule interchange format since rules expressing policies are to be exchanged between parties engaged e.g. in negotiations.
- The actors (e.g. buyer and seller) can communicate in a precise, informative, and automated fashion, about important aspects of transaction authorization and access control.
- Actors can use different rule engines/languages. E.g., a production rules systems or Prolog systems.
- The policy rules are reusable across multiple tasks of different domains.
- Actors can reason automatically with the policy rules e.g. as part of evaluating the prospective value of the proposed deal or for reaching a contractual agreement. They can avoid having to have human(s) read the policies in natural language text and then integrate that understanding into the process of decision-making.
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
Automated Trust Establishment for eCommerce
- 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.
Credit Card Transaction Authorization
- eSellWow - merchant of credit card transactions
- The bank - credit card issuer
Refund Policies in E-Commerce, Supply Chain Ordering Lead Time, Price Discounting
- A seller or merchant - shares rules about refund policies, supply chain ordering lead time policies or price discounting policies to be used in e-contracting (e.g. in contract proposals, agreed-upon contracts, or post-agreement monitoring of contract complience and performance)
- A set of prospective buyers or customers
8.2. Main Sequence(s)
Automated Trust Establishment for eCommerce Alice would like to buy online a new device at an eShop. Alice's and eShop's systems negotiate with the purpose of purchasing the device, that is the systems disclose relevant policies and credentials.
The use case Automated Trust Establishment for Accessing Medical Records is very similar to Automated Trust Establishment for eCommerce, the only difference is that some of the policy rules are to be hidden in the first scenario.
Credit Card Transaction Authorization Actors have their own policy rules that are used in the process of credit card transaction authorization: eSellWow has a group of rules which are adopted or imported from a vendor and consultant when setting up its e-store Web site. The bank has also a group of rules stating conditions on credit cards in authorizing transactions. A set of background fact rules are also used in the process, some of them are known to both eSellWow and the bank, some of them just to one of these actors.
- The seller posts the refund policy rules on his/her Web site, or sends in a message to a prospective buyer.
- Various buyers get the refund policy rules and reason with them as part of making their decision about whether to purchase. Some do indeed purchase.
- Some buyers return the item to the seller and want a refund. The rules determine how much percentage of their money paid is refunded, depending on the circumstances.
A slight modification of the above given sequence is found in the use case Supply Chain Ordering Lead Time. An extension of this use case involves action rules for e.g. sending notifications or doing payments via triggered procedural attachements. The use case Price Discounting states simple circumstances in which discounts are offered; it doesn't come with new requirements on the RIF.
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.
Bank says by default the transaction is authorized if the card is in good standing.
Bank says the transaction is disallowed if the card is expired.
Bank says the transaction is disallowed if the card is above its account limit.
Bank says the transaction is disallowed if the expiration date from the customer or card in the transaction does not match what's on file for the card. (Note, however, that the expiration date may not be available as part of the transaction.)
Bank says the transaction is disallowed if the Card Verification Code does not match what's on file for the card. (Note, however, that the CVC may not be available as part of the transaction.)
Bank says the transaction is disallowed if customer-supplied cardholder billing address does not match what's on file for the card. (However, the customer-supplied cardholder billing address may not be available.)
Bank says the transaction is disallowed if customer-supplied cardholder name does not match what's on file for the card. (However, the customer-supplied cardholder billing address may not be available.)
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.
Merchant says a transaction is disallowed if the bank does.
Merchant says, by default, that a transaction is allowed if the bank does.
Merchant says transaction is disallowed if a trusted fraud tracking service rates the fraud risk as high for the card.
Merchant relies on recommenderServiceTRW for establishing such trust.
Merchant says transaction is disallowed if its own/other experience indicates that the customer is a bad customer to deal with.
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.
eSellWow is an established merchant for mastercard and visa.
Additional rules known to the merchant
The following are additional background fact rules, known to the merchant eSellWow.
recommenderServiceTRW recommends fraudscreen
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:
A gold card holder is given a 10% discount on any purchase.
An eShop employee gets 20% discount on devices of this type.
Any other buyer must provide to the shop credit card information together with delivery information (address, postal code, city, and country). 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
if the client is in the eShop client blacklist then deny purchase request;
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
to never disclose two different credit cards to the same online shop and
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.
9.2.2. Comments on Interoperability vs. Interchange
Interoperability
- the actors need to interact in real time to complete a transaction
- the way the transaction is carried out, its success and failure, depend on the policies (rulebases) independently adopted by the two peers
Interchange
- the process of transferring rules must preserve the rule meaning literally
- at each negotiation step one peer physically sends some rules of its policy (or a filtered form thereof) to the other peer (policies need to be shared, typically in real time).
- rule interchange is necessarily done during negotiation because in general it depends on the current level of trust that peers have on each other - in practice, some rules can be disclosed and sent off only after the other peer has sent some of its credentials
- the common metamodel shared by the peers covers only a small set of predicates with a negotiation-related meaning (basically an encoding of X.509 credentials and web forms) and a shared understanding of logical connectives (i.e. rule semantics)
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: http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html .
[7] Benjamin Grosof. DIPLOMAT: Compiling Prioritized Default Rules Into Ordinary Logic Programs, for Electronic Commerce Applications (Extended Abstract of Intelligent Systems Demonstration). Available at http://ebusiness.mit.edu/bgrosof/#cr-ec-demo-rr-99b.