1. May 28, 2002Mårten Trolin1 Protocols for e-commerce Traditional credit cards SET SPA/UCAF 3D-Secure Temporary card numbers Direct Payments

2. May 28, 2002Mårten Trolin2 Traditional credit cards Cardholder enters his credit card number at the merchant’s site. Merchant sends card number to his acquirer. If authorization is given from the issuer, the purchase is approved.

3. May 28, 2002Mårten Trolin3 SET SET (Secure Electronic Transaction) gives authentication of the cardholder. On registration, the cardholder gets a certificate from the issuer. Special software (wallet) is installed on the cardholder’s computer.

4. May 28, 2002Mårten Trolin4 A SET purchase 1. When the cardholder pays for a purchase, the wallet is activated and signs the transaction. 2. The merchant sends the signature to his acquirer, who passes it on to the payment gateway. 3. The payment gateway verifies the cardholder’s signature and certificate, and sends an ordinary request to the issuer. 4. The issuer decides whether to approve or decline the purchase. 5. The response is sent to the merchant via the payment gateway.

5. May 28, 2002Mårten Trolin5 SPA/UCAF In UCAF (Universal Cardholder Authentication Field) an extra field identifying the client is sent to the issuer. On registration the client receives a piece of software that can connect to the issuer and receive the authentication code. Technology from MasterCard/Europay.

6. May 28, 2002Mårten Trolin6 A SPA/UCAF purchase 1. The cardholder chooses to pay for goods or services. 2. Hidden fields (html tags) activate the cardholder application. 3. The cardholder application connects to the issuer. The cardholder authenticates himself and receives a code. 4. The cardholder sends the code to the merchant. The merchant passes it on to the issuer. 5. The issuer compares the received code with the code it issued. If they match the purchase can be approved.

7. May 28, 2002Mårten Trolin7 3-D Secure 3-D Secure can use an existing relationship between a cardholder and issuer. When a purchase is made, the cardholder is redirected to his issuer for authentication. Supported by Visa.

8. May 28, 2002Mårten Trolin8 A 3-D Secure purchase 1. The cardholder wishes to pay and enters his credit card number. 2. The merchant connects to the directory service to find out whether 3-D Secure is enabled for the account. If it is, the merchant receives a URL. 3. The cardholder is redirected to the URL received. Here he authenticated himself through a method chosen by the issuer (password, certificates, smart-card etc.). The cardholder receives a digital signature approving the purchase. 4. The digital signature is sent to the merchant who can verify it.

9. May 28, 2002Mårten Trolin9 Temporary card numbers Temporary card numbers use the existing infrastructure. The cardholder receives several card numbers, either in a batch or interactively. When making a purchase, he uses one of the numbers, which becomes invalid after use.

10. May 28, 2002Mårten Trolin10 Problems with plain credit card numbers The problem with sending the card number directly is that no authentication is performed. Card numbers are quite easy either to generate or to find from slips etc. If a cardholder disputes a purchase, the merchant has no proof.

11. May 28, 2002Mårten Trolin11 SET SET was the first protocol for secure online purchases. – Purchases are digitally signed, giving the merchant proof of purchase. Requires a new infrastructure, and has not been very successful. The complexity of SET was the reason why new methods were introduced.

12. May 28, 2002Mårten Trolin12 SPA/UCAF and 3-D Secure SPA/UCAF and 3-D Secure address the problems with SET. They build a secure frame-work on top of the existing infrastructure. – As in SET, purchases come with a digital receipt. Require little or no extra actions from the cardholder.

13. May 28, 2002Mårten Trolin13 Temporary card numbers Quick and easy solution to solve the problems with card number only purchases. Requires no extra development except for generation of temporary card numbers. Card numbers are a limited resource. Merchant gets no proof of purchase.

14. May 28, 2002Mårten Trolin14 Direct payments When direct payments are used, the client pays directly from his Internet bank account. Since the authentication uses the existing relationship between the client and the bank, no new software is necessary for the client.

15. May 28, 2002Mårten Trolin15 A direct payment purchase 1. When the client wishes to pay, he chooses direct payment as the payment method. 2. The merchant creates a link to the client’s bank. 3. The client clicks on the link and is redirected to the bank. 4. The client approves the purchase, funds are checked. If the bank approves, a MAC or digital signature is created and sent to the merchant (either directly or via the client’s browser). 5. The merchant checks the digital receipt.

16. May 28, 2002Mårten Trolin16 Direct payments Uses existing infra-structure. No new software necessary for client. No standards. Extra development for each new bank. Not clear how foreign currencies are handled. Avoids the fees imposed by the credit card companies.

17. May 28, 2002Mårten Trolin17 Summary Sending credit card only has security problems. – Purchases not authenticated. Several methods exist to solve this problem. – SET – 3-D Secure – SPA/UCAF 3-D Secure and SPA/UCAF minimize the problems for the cardholder. For each purchase, the client gives approval directly to his issuer.