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, 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.
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
( ) contain a description of the goods in order to provide
one-sided certified delivery. The goods (
) 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
( ) 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
, 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 (
). The bank must
verify the validity of
, including a check against reuse. The
bank then uses
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 ( ) 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 ( ) has not passed.
In step 1, the log records the merchant's commitment if it
was received before . 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 , 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
is generated,
the purchase protocol terminates.