next up previous
Next: Correctness and Atomicity Up: Protocols Previous: Withdrawal and Exchange

Purchase

 

Some negotiation of the transaction contract is assumed to take place prior to the transaction steps listed below. Given the current approach, the method of this negotiation has no direct bearing on the protocol. As above, each message is annotated with a mnemonic which describes the purpose of the message, and which will be used to refer to the message. For example, tex2html_wrap_inline840 denotes the authorization action by the party identified in the subscript. The protocol is an example of linear commitment is the sense defined in [10]. The steps of the purchace protocol are given in Figure 3.

 

        figure207


Figure 3: Purchase protocol.

In step 1, the merchant sends a signed copy of the contract and goods to the consumer. It is essential that the contract ( tex2html_wrap_inline866 ) contain a description of the goods in order to provide one-sided certified delivery. The goods ( tex2html_wrap_inline868 ) are encrypted with a single-use private key (k), referred to as the merchandise key. The merchandise key will be revealed to the log and the consumer if the transaction commits. The message includes a transaction number (n) generated by the merchant which should be different from any previously generated transaction number from the same merchant. A duplicate number could be detrimental only to the merchant. Upon receipt, the consumer verifies that the contract is acceptable.

In step 2, the consumer decides upon an expiration time ( tex2html_wrap_inline874 ) for the transaction, after which the transaction is considered to have failed, and the token can be reused or replaced. The consumer also selects a transaction log (L) for the transaction. Both the bank and the merchant have effective veto power over the consumer's selection of L and tex2html_wrap_inline874 , since they will not provide authorization before knowing these values. The consumer then signals to the bank its readiness to commit by specifying the transaction and the token and key to be used ( tex2html_wrap_inline754 ). The bank must verify the validity of tex2html_wrap_inline754 , including a check against reuse. The bank then uses tex2html_wrap_inline754 to check the message's signature.

In step 3, the bank tells the merchant that it and the consumer are ready to commit, and includes in the message the value of the token ( tex2html_wrap_inline888 ) to be used for payment. The merchant verifies the transaction number is correct and that the token value, log identity, and expiration time are acceptable.

In step 4, the merchant commits to the transaction by sending the merchandise keyto the log, along with the time-out, transaction number, and a signature. Upon receipt, the log verifies that the expiration time ( tex2html_wrap_inline874 ) has not passed.

In step 1, the log records the merchant's commitment if it was received before tex2html_wrap_inline874 . The precise method of distribution of the recorded message is not important to determining atomicity properties, but some method for providing timely, good-faith delivery to the consumer is of practical importance. Any party can use this log record in conjunction with other signed messages obtained during the transaction to force the bank to transfer funds or to obtain the goods decryption key, completing the transaction.

In step 2, which may occur only after the tex2html_wrap_inline874 , the log generates a negative authorization at the request of the consumer or the bank. This indicates that no 4 for the given merchant and transaction number was received prior to the given expiration time. This allows the token to be freed for reuse or exchanged following a failed transaction; after tex2html_wrap_inline896 is generated, the purchase protocol terminates.


next up previous
Next: Correctness and Atomicity Up: Protocols Previous: Withdrawal and Exchange

TOM Comversion
Fri Oct 4 18:57:08 EDT 1996