SET was developed by the SET Consortium, established in 1996 by Visa and Mastercard in cooperation with GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems, RSA, and VeriSign. The consortium’s goal was to combine the card associations' similar but incompatible protocols into a single standard. SET allowed parties to identify themselves to each other and exchange information securely. Binding of identities was based on X.509 certificates with several extensions. SET used a cryptographic blinding algorithm that, in effect, would have let merchants substitute a certificate for a user's credit card number. If SET were used, the merchant itself would never have had to know the credit-card numbers being sent from the buyer, which would have provided verified good payment but protected customers and credit companies from fraud. SET was intended to become the de facto standardpayment method on the Internet between the merchants, the buyers, and the credit-card companies. Unfortunately, the implementation by each of the primary stakeholders was either expensive or cumbersome. There were also some external factors that may have complicated how the consumer element would be integrated into the browser. There was a rumor circa 1994-1995 that suggested that Microsoft sought an income stream of 0.25% from every transaction secured by Microsoft's integrated SET compliant components they would implement in their Internet browser.
Key features
To meet the business requirements, SET incorporates the following features:
Both cardholders and merchants must register with the CA first, before they can buy or sell on the Internet. Once registration is done, cardholder and merchant can start to do transactions, which involve nine basic steps in this protocol, which is simplified.
Customer browses the website and decides on what to purchase
Customer sends order and payment information, which includes two parts in one message:
:b. Card information – this part is for merchant’s bank only.
Merchant forwards card information to their bank
Merchant’s bank checks with the issuer for payment authorization
Issuer sends authorization to the merchant’s bank
Merchant’s bank sends authorization to the merchant
Merchant completes the order and sends confirmation to the customer
Merchant captures the transaction from their bank
Issuer prints credit card bill to the customer
Dual signature
As described in : The message digest of the OI and the PI are independently calculated by the customer. These are concatenated and another MD is calculated from this. Finally, the dual signature is created by encrypting the MD with the customer's secret key. The dual signature is sent to both the merchant and the bank. The protocol arranges for the merchant to see the MD of the PI without seeing the PI itself, and the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using the MD of the OI or PI, without requiring either the OI or PI. Privacy is preserved as the MD can't be reversed, which would reveal the contents of the OI or PI.
