This is one of the possible Use Cases.
1. Abstract
This is a medium-length use case about credit card transaction authorization. (By BenjaminGrosof)
This is a relatively long and realistic example of authorization in e-commerce: authorization by a merchant of credit card transactions requested by customers. In this example, the merchant ("eSellWow") merges the authorization policies of credit card issuer (called the "bank") with the merchant's own additional authorization policies. These rules are useful in security authorization, and as part of contract formation/negotiation, and as part of contract monitoring / exception handling (e.g., if the fraud alert arrives after contractual agreement has been reached).
2. Status
This use case is submitted by BenjaminGrosof.
It's mostly done, but still undergoing some editing.
This example is taken from the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof, Chitravanu Neogy, and Shashidhara Ganjugunte, available at: http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html .
The description here is modified to be closer to the requested use case template for RIF, but the rules are unmodified.
The example first appeared in this form in the SWSF design report
-> Application Scenarios document
-> section on Policy Rules for E-Commerce.
(http://www.daml.org/services/swsf/1.0/ -> ...). Earlier shorter versions of similar credit policy example(s) appeared in the SweetRules V2+ download examples and the IBM CommonRules V1+ download examples.
The rules are given in the RuleML/SWSL presentation syntax. A primer on that syntax is given below as an appended section, is also in the above paper, and full details about it are in the above SWSF design report.
Implementation:
This example has been implemented in SweetRules V2 (and in earlier form, in IBM CommonRules).
Frequency/importance in real world:
- This is a very common and important kind of policy in real-world commerce, both electronic and non-electronic.
3. Benefits of Interchange
* The policy rules from the bank can be merged (by the merchant) with those originating from the merchant itself, in a modular and semantically clean/clear fashion.
- The merchant and the bank (and the customer) can use different rule engines/languages. E.g., a production rules systems or Prolog systems.
- The credit card authorization policy rules are reusable across multiple tasks in security and e-contracting, including: security authorization, contract formation/negotiation, and contract monitoring/exception-handling (e.g., if the fraud alert arrives after contractual agreement has been reached).
Which Rule Systems Supported:
The Courteous LP feature is supported in RuleML/SWSL, SweetRules, and IBM CommonRules (and its BRML). SweetRules implements it on top of / in Jess production rules and/or XSB Prolog rules, by i.e., by translating to and from those via a "courteous compiler" component.
SweetRules includes an open source such courteous compiler component.
4. Requirements on the RIF
- The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to merge/add new rules, e.g., that represent the bank's policies or how to handle special-cases/exceptions.
- The prioritized defaults here involve in particular an integrity constraint that one should not conclude that the same request is both allowed (authorized) and disallowed. This is represented elegantly using the strong-negation connective (and associated implicit mutex) that Courteous LP features.
5. Breakdown
5.1. Actors and their Goals
List the different parties who interact in this use case, along with their goals. They should be named with abstract role names, like "Buyer", "Seller", "Buyer's Agent", and "Government Agency".
Actor 1 - wants ...
...
Actor n - wants ...
5.2. Main Sequence
Next, we give a longer and more realistic example of authorization in e-commerce: authorization by a merchant of credit card transactions requested by customers. In this example, the merchant ("eSellWow") merges the authorization policies of credit card issuer (called the "bank") with the merchant's own additional authorization policies. These rules are useful for specifying authorization policies, contracts, and exception handling.
/* Some terminological abbreviations: CVC: Card Verification Code (the three or so numbers found on the back of a credit card) "Bank": the credit card company that is the issuer of the credit card (e.g., Mastercard) */ /* Predicates' meaning:
transactionRequest: a credit card transaction requested by a customer merchant: a merchant who is established to do credit card transactions with the credit card company ccInGoodStanding: credit card is in good standing with the credit card company that is the issuer of the credit card ccInfo: credit card info about the account and its status, that is on file with the bank authorize: the credit card transaction is authorized transactionExpirationDateOf: customer-supplied expiration date that is part of the transaction transactionCardholderNameOf: customer-supplied cardholder name that is part of the transaction transactionCVCOf: customer-supplied CVC that is part of the transaction transactionCardholderAddressOf: customer-supplied cardholder billing address that is part of the transaction ccFraudRating: rating of a credit card by a fraud alerting/tracking service fraudExpert: a service is a legitimate expert in fraud alerting/tracking fraudRecommenderFor: trusted recommender of fraud experts customerRating: the rating of customer based on the merchant's own/other experience
Built-in predicates (used): notEquals lessThan */
/* The following group of rules are policies of the bank, then adopted/imported as a group/module by the merchant, in this case eSellWow. */
/* bankGoodStanding: Bank says by default the transaction is authorized if the card is in good standing */ /* expiredCard: Bank says the transaction is disallowed if the card is expired. */ /* overLimit: Bank says the transaction is disallowed if the card is above its account limit. */ /* mismatchExpirationDate: 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. However, the expiration date may not be available as part of the transaction. */ /* mismatchCVC: Bank says the transaction is disallowed if the Card Verification Code does not match what's on file for the card. However, note that the CVC may not be available as part of the transaction. */ /* mismatchAddress: 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. */ /* mismatchName: 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. */ /* The expiredCard, overLimit, mismatchExpirationDate, mismatchCVC, mismatchAddress, and mismatchName rules all have higher priority than bankGoodStanding. */
/* The following group of rules are additional policies of the merchant eSellWow, which it adopted/imported from a vendor and consultant when setting up its e-store website */ /* merchantRespectBank: Merchant say a transaction is disallowed if the bank does. */ /* merchantTrustBank: Merchant says, by default, that a transaction is allowed if the bank does. */ /* fraudAlert: Merchant says transaction is disallowed if a trusted fraud tracking service rates the fraud risk as high for the card. */ /* trustTRW: Merchant relies on recommenderServiceTRW for establishing such trust. */ /* badCustomer: Merchant says transaction is disallowed if its own/other experience indicates that the customer is a bad customer to deal with. */ /* The fraudAlert and badCustomer rules both have higher priority than merchantTrustBank. */
/* The following are additional background fact rules, known to the merchant eSellWow and the bank. */ /* eSellWow is an established merchant for mastercard and visa. */
/* The following are additional background fact rules, known to the merchant eSellWow. */ /* recommenderServiceTRW recommends fraudscreen */
{bankGoodStanding} authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInGoodStanding(?Bank,?CreditCardNumber).
{expiredCard} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
notEquals(?ExpiredFlag,"false").
{overLimit} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
lessThan(?AccountLimit,?Amount).
{mismatchExpirationDate} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionExpirationDateOf(?TransactionID,?TransactionExpirationDate) and notEquals(?TransactionExpirationDate,?ExpirationDate).
{mismatchName} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionCardholderNameOf(?TransactionID,?TransactionCardholderName) and notEquals(?TransactionCardholderName,?CardholderName).
{mismatchCVC} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
{mismatchAddress} neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionCardholderAddressOf(?TransactionID,?TransactionCardholderAddress), notEquals(?TransactionCardholderAddress,?CardholderAddress).
overrides(expiredCard,bankGoodStanding). overrides(overLimit,bankGoodStanding). overrides(mismatchExpirationDate,bankGoodStanding).
overrides(mismatchName,bankGoodStanding). overrides(mismatchCVC,bankGoodStanding). overrides(mismatchAddress,bankGoodStanding).
{merchantTrustBank} authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and authorize(?Bank,?TransactionID).
{merchantRespectBank} neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and neg authorize(?Bank,?TransactionID).
{fraudAlert} neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
fraudExpert(?recommenderService,?FraudFirm) and ccFraudRiskRating(?FraudFirm,?CardholderName,high).
{badCustomer} neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
customerRating(?Merchant,?CardholderName,bad).
overrides(fraudAlert,merchantTrustBank).
overrides(badCustomer,merchantTrustBank).
fraudRecommenderFor(eSellWow,recommenderServiceTRW).
merchant(eSellWow,mastercard).
merchant(eSellWow,visa).
fraudExpert(recommenderServiceTRW,fraudscreen).
/* 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). */
transactionRequest(trans1014,eSellWow,"999912345678",70). issuer("999912345678",mastercard). ccInfo("999912345678",mastercard,joeGoya,1100,"false","2007_08","43 Garden Drive, Cincinnati OH",702). ccInGoodStanding(mastercard,"999912345678"). customerRating(eSellWow,joeGoya,good).
transactionRequest(trans2023,eSellWow,"999987654321",410). issuer("999987654321",visa). ccInfo("999987654321",visa,maryFreund,2400,"false","2008_02","325 Haskell Street, Seattle, WA",684). ccInGoodStanding(visa,"999987654321"). ccFraudRiskRating(fraudscreen,maryFreund,low). customerRating(eSellWow,maryFreund,excellent). transactionCVCOf(trans2023,524). transactionTransactionAddressOf(trans2023,"1493 Belair Place, Los Angeles, CA").
transactionRequest(trans3067,eSellWow,"999956781234",120). issuer("999956781234",mastercard). ccInfo("999956781234",mastercard,andyLee,900,"false","2006_05","1500 Seaview Boulevard, Daytona Beach, FL",837). ccInGoodStanding(mastercard,"999956781234"). customerRating(eSellWow,andyLee,bad).
The above premises (policy rules and case facts) together entail the following conclusions about the authorization of the particular requested transactions by customers Joe Goya, Mary Freund, and Andy Lee. Notice that in the case of Andy Lee's, the merchant denies authorization even though the bank approves it, because of the merchant's own customer rating info and policies.
/* the entailed approval vs. denial by the bank, and by the merchant, of authorization of the particular requested credit card transactions. */
authorize(mastercard, trans1014). authorize(eSellWow, trans1014).
neg authorize(visa, trans2023). neg authorize(eSellWow, trans2023).
authorize(mastercard, trans3067). neg authorize(eSellWow, trans3067).
5.3. Alternate Sequences
Describe possible variations of the main sequence in separate subsections, assigning a title to each.
5.3.1. (Title of Alternate Sequence)
Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).
6. Narratives
Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.
6.1. (Title of Narrative)
Describe an individual scenario. Samples rules and other test data may be optionally included.
7. Commentary
Considerable commentary was given above, already.
More relevant commentary is in the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof et al, from which this example is taken (http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html). Please see the Abstract and Section 1 there.
7.1. PRIMER on RuleML/SWSL presentation syntax for CLP:
Next, we give a quick primer on RuleML presentation syntax, to aid the beginner to read examples of policies, in particular to read those in the next section and in the Policy Rules for E-Commerce section of the SWSF Application Scenarios (mentioned above). Full details of this presentation syntax are given in the SWSL (i.e., SWSF Language) document. But that's rather long and technical, so it's useful to have this primer. Note this primer only covers/treats part of the overall presentation syntax.
Next we describe some key syntactic constructs:
"?" prefixes a logical variable. ":-" is the implication connective. It means "if". Thus head-expression :- body-expression means "head-expression if body-expression", i.e., "if body-expression then head-expression". Note that a rule can be simply a fact; in this case, the body expression is empty/absent, and the ":-" connective can be (and usually is) omitted. "." ends a rule statement. "{...}" encloses a rule label. The rule label precedes the rest of the rule. Such a label is essentially a a name for the rule; it is used as a handle for specifying prioritization. "overrides" is a special predicate that is used to define prioritization between rules. overrides(lab1,lab2) specifies that any rule having label lab1 has higher priority than any other rule having label lab2. "!-" begins a mutex, i.e., a mutual-exclusion integrity constraint statement. !- can intuitively be read as "It's a logical contradiction if". In such a mutex, "|" can be read as "given that". "neg" is the classical negation connective. It means "not". Intuitively, "neg p" means that p is believed to be false. By contrast, "naf" is the negation-as-failure connective. It means "not believed". Intuitively, "naf p" means that p is not believed to be true. It may be that neither "p" nor "neg p" is believed, i.e., that the truth value/status of p is unknown. "naf" is thus weaker than "neg". For those less expert in the technical aspects of rules, it can be confusing to employ both "neg" and "naf" in the same rule or ruleset, so it is often helpful to employ (explicitly) only "neg" when writing rules.