5. On receiving the message, FSP verifies the client’s signature and retrieves the payment confirmation. Then, FSP forwards the confirmation to the bank.
6. FSP sends the notification to the merchant.
7. FSP also sends the payment receipt to the client.
Antovski et al. do not provide the details of each message transferred in the protocol. They claimed that the protocol is suitable for wireless environments. However, it’s computational and communication load are still doubtful because this protocol deploys public-key operations, especially at the client side.
An agent-based payment system applies mobile agent technology to existing payment systems to enhance the Dai et al.’s Approach
Dai et al. proposed a payment system that allows clients perform transactions via mobile phones. Three parties are involved in this system: client, WAP gateway, and merchant. The client is assumed to have a WAP-enabled mobile phone, whereas the merchant has an e-commerce WAP site. This system deploys a WAP gateway to perform secure operations on behalf of the client. Dai et al. argued that a WAP1.2 phone is capable of generating digital signature according to PKCS#1 standard which cannot provide signature validation process. Note that the signature validation process is provided by the PKCS#7 standards.
To solve this problem, Dai et al. introduced a secure module into the WAP gateway to perform the functions that cannot be done on the WAP phone such as storing certificates, generating signatures according to PKCS#7 standard, and validating the merchant’s signature. Dai et al. also proposed an authentication and payment scheme based on this system. The client authentication scheme for this system can be simplified in Figure 2.4 as follows:
Figure 2.4: The authentication scheme according to Dai et al.’s approach.
The client sends an authentication request to the merchant via the WAP gateway.
The merchant generates an authenticate message to the client via the WAP gateway and a SMSC (Short Message Service Center).
The client signs the message with PKCS#1 signature and passes it to the WAP gateway via the SMSC.
The WAP gateway verifies the signature. It signs the message with PKCS#7 signature and sends to the merchant.
The payment scheme for this system is shown in Figure 2.5 as follows:
Figure 2.5: The payment scheme according to Dai et al.’s approach
The client sends a request to the merchant via the WAP gateway.
The merchant sends back the payment type, e.g. credit or debit, to the client via the WAP gateway.
The client selects the payment type preferred to the WAP gateway.
The WAP gateway sends a contract to the client via the SMSC.
The client signs the contract with PKCS#1 signature and sends it back to the WAP gateway via SMSC.
The WAP gateway verifies the signature and performs the transaction on behalf of the client to the merchant.
The merchant sends the receipt to the client via the WAP gateway.
In this system, it is obvious that the security of the client relies on the security and trustworthiness of the WAP gateway. That is, the WAP gatewayis able to impersonate as the client because it has the client’s private key. Moreover, the use of SMSC is unnecessary because the entire transaction can be performed with the direct communications between the client and the WAP gateway. The use of SMSC also incurs extra cost for the client in addition to being charged for the WAP usage. That is, in each transaction, the client has to be charged for two SMS messages: one in the client authentication phase and the other in the payment phase.
capability of performing transactions in wire- less environments. The concept is that a mobile client sends an agent, acting on her behalf, containing payment-related information, to perform a transaction in a merchant’s environment over a fixed network. With the use of mobile agent, the client is required to stay connected to the Internet only for short periods of time during the entire transaction. This results in the reduction of connection cost. Moreover, the computation load at the client is reduced because the agent performs the transaction outside the client’s environment.
In this section, two agent-based mobile payment systems, SET/A RdS98 and SET/A+ WLY99, are presented and discussed in details.
SET/A is an agent-based SET payment system proposed by Romao et al. 25 in order to solve the problems of implementing SET protocol 26 in wireless environments previously discussed in section 2.3.1. The concept of SET/A is to let a mobile agent perform a transaction on behalf of a client outside the client’s environment.
In SET/A, the original SET protocol is operated in asynchronous mode.
The operations of SET/A can be depicted in Figure 2.6.
Figure 2.6: SET/A
The client starts a SET initialization request by sending an agent con- taining the client-side software called SET wallet together with payment- related information travelling to the merchant’s server and staying there in order to perform a transaction on behalf of the client. From Figure 2.6, A(C) represents the agent owned by the client.
At the merchant’s server, the client’s PReq is generated and sent to the merchant.
The merchant performs the transaction as per the original SET proto- col (as presented in section 2.3.1) until receiving AuthRes from the payment gateway.
After receiving AuthRes, the merchant generates PRes and passes it to the agent residing in the merchant’s server itself.
After receiving PRes, the agent returns to the client with the result of the transaction.
It can be seen that, with the use of mobile agent, the client stays connected to the Internet only two short periods of time: one for sending the agent con- tainting the client’s request to the merchant at the beginning of the transaction and