4.4 Discussions
4.4.1 Issuer
In our SET payment system, the issuer maintains the tasks of the proxy server. In other words, the role of the issuer increases from that of original SET payment system in that it acts as an assistant of the client on performing transactions. This is because the issuer (such as the client’s bank) has the database which contains the client’s information including credit-card infor- mation (CCI). Therefore, the client’s credit-card information does not have to be transmitted over the air interface as in SET/A [RdS98]. The client has to send only h(CCI) to compare with the hash value of its pre-image (CCI)
stored in the issuer’s database. If they are matched, the issuer issues the valid credit-card information to the payment agent PA in order to establishPReq. Note that deploying SET protocol in the proposed framework does not affect the role of the issuer in our system. Normally, its tasks are the same as those of the original SET payment system. The additional tasks are only acting as the assistant of the client on issuing the credit-card information and the assistant of the payment agent PA on performing high computational operations. The message brought with PA travelling away from the issuer contains the same structure as that of the original SET’s PReq. Moreover, the issuer cannot impersonate as the client although it has the client’s CCI. To generatePReq, the issuer needs to have the client’s private key. This is a security enhancement of our system compared to 3D SET for Mobiles [WSZ01], a proxy-based SET payment system.
It could also be noted that the issuer would cooperate in this system be- cause, from the business point of view, this would be a payment service which results in the benefit to the issuer in that it is able to increase the number of clients as well as the number of financial transactions.
4.4.2
Trust Relationships among Engaging Parties
In SET protocol, the payment gateway acts on behalf of the issuer and the ac- quirer at the Internet side. It decrypts the client’s payment information (P I) which contains the client’s credit-card information, collects relevant informa- tion regarding the requests from both client and merchant, and then passes this information to the issuer and the acquirer. It can be seen that the pay- ment gateway must be a party who is trusted by the client in that it will not reveal the client’s credit-card information. Thus, the payment gateway must be operated by a credit-card company or a bank that issues its own credit cards. However, the payment gateway is not always a credit-card company,but possibly a company that monitors the SET payment system on behalf of the issuer.
From the above argument, it can be seen that our formal model is not only more general, but more precise than the SET payment model in regards of the trust relationships among engaging parties in the payment system. Note that the Definition 3.11 of the formal model states the trust relationship between the client and the issuer instead of the client and the payment gateway (or P SP in the model). We can see that the proposed model is more general in that the issuer can be considered as the payment gateway communicating with the client/merchant over the Internet side. It is more precise in that the payment gateway is not trusted by the client as the issuer is trusted as the party to which the client has to reveal sensitive information. However, the issuer is not fully trusted by the client in our formal model, that is, only the partial trust relationship between them is established. The issuer must not be able to impersonate as the client. In our system, the issuer cannot impersonate as the client because it does not have the client’s private key, only the client’s credit-card information is stored at the issuer. As a result, our system satisfies this property, whereas the proxy-based system does not.
Moreover, to make the SET protocol operate in a larger scope, the trust relationship between the client and the payment gateway needs to be reorga- nized in a way that the payment gateway is not trusted by the client that it will not reveal the client’s sensitive information to other parties. From this argument, it can be seen that the payment system based on the original SET protocol does not satisfy the Definition 3.11 of the formal model. To solve this problem, enciphering the client’s credit-card information, e.g. using hash function, is suggested.
However, in the proposed payment system, we do not modify the trust re- lationship between the client and the payment gateway as mentioned above. This is because we primarily concern about the practicability of the system in
that existing fixed-network users must be able to perform SET payment trans- actions without any modification required on their SET payment software. Note that, the above trust relationship will be applied to our account-based mobile payment protocols in chapter 5.