In general, PIN codes are generated by banks, and passwords for services are maintained by service providers though they are generated by service users. Personal secrets like PIN codes are not protected by separation of duty, and this creates a security gap. We showed how to transfer responsibility for secrets to customers in a practical system. Customers generate and maintain their personal secret to access a service. As a result, the service provider is less exposed to the maintenance of customers' secret data. There are no critical customer secrets on the service provider's side.
To minimise communication costs, off-line
transactions are preferred in some cases.
To make transactions off-line, one has to be able to postpone procedures
between the merchant and the bank for some time, and the proof of
purchase has to be issued to the customer when the purchase is made.
After receiving 
from the customer, the merchant can issue
as the proof of purchase, and the transaction
between the customer and the merchant is done. In this case, the merchant
does not have a guarantee from the bank, since there is no communication
with the bank. As in current off-line transactions using a cheque and
cheque guarantee card, we can set a certain credit limit for such transactions
and guarantee the merchant his money.
The merchant cannot request a different amount of
money to bank from the amount in , since contains
, and both the customer and the bank will have a hash quantum
containing the amount u. The customer is also protected.
Existing electronic banking systems keep a file of merchant-customer tuples
for authorised transactions.
Thus the storage of will not be a problem in practice.
Indeed, limiting the transaction beneficiaries is an important control of fraud, and
desirable in the case of off-line merchant transactions.
In effect, our scheme allows new merchants to be registered quickly,
but only provided the customer, the merchant, and the bank are all on-line
at once.
As an alternative of hash functions for our scheme, we could use
Message Authentication Codes (MACs). During the registration procedure,
principals share secrets between the customer and the bank, and
between the customer and the merchant. When we adopt a MAC for the
scheme, these secrets can be used as keys for the MAC without further effort.
By the nature of MACs, hashed values can be seen only by key sharers.
But it does not help reduce the complexity of the scheme.
This scheme provides non-repudiation of both ordering and payment.
A merchant cannot make a false transaction without
a customer's participation, because he does not have the customer's secret
such as 
and .
Since a customer has to send a merchant the hash
of a payment id and her private information registered in the bank,
the customer cannot deny that the transaction was done by her.
For both principals, a merchant and a customer, they cannot forge a transaction
by denial for the transaction.
One of the underlying ideas is a customer-oriented transaction; a customer plays a central role in setting up relations to a bank and merchants and making transactions, and keeps her secrets against other principals. Collusion between a bank and a merchant is not so helpful in this model.