In the e-commerce world, the most widely accepted form of identification is a certificate from a CA (certificate authority). In fact, e-commerce requires a secure browser and HTTP server, as well as a trusted third-party CA. Digitally signed by VeriSign or Entrust, a CA authenticates the merchant; proof of identity protects the merchant from one customer attempting to impersonate another.

A user's certificate contains his or her public keys, which the browser delivers with the issuing CA's secret key. The merchant presents that message to the issuing CA, and the CA computes the cryptographic "checksum" and returns it to the merchant. The certificate is then stored, confirming its authenticity. ("CyberCash Secure Internet Credit-Card Payment," above, shows the steps necessary to create and verify a digitally signed message.)

Support for SSL is a necessary building block for any commerce site. The CA protocols and SSL form the basis for nonrepudiation of origin, server authentication, integrity and confidentiality. They provide these higher-level services above IP to any application, such as HTTP, FTP or telnet. Created by Netscape Communications Corp. and serving as the foundation for the IETF TLS (Transport Layer Security) standard, SSL encapsulates data into transactions and guarantees the confidentiality and integrity of the transaction's individual blocks. The SSL handshake protocol is used to negotiate what encryption algorithms will be used, so appropriate plug-ins can support encryption. The merchant sends its certificate and challenges the consumer, while the client returns its certificate and signs the challenge message. (Both the merchant and the consumer must recognize the CA.) The SSL Record Protocol provides the support for fragmentation, compression and encryption.

In addition to the mechanisms described above, a typical e-commerce site uses CyberCash, the most popular implementation of these protocols for small and midsized e-commerce sites. (CyberCash documented an early version of its protocol in RFC 1898.) It relies on CA protocols for authentication, along with SSL for secure pipes between the consumer's wallet, the Web server commerce package and the CyberCash gateway. CyberCash takes the transaction from the Internet and uses the protocols over dedicated lines. It establishes value by transporting the credit-card information and response to and from the carrier, so the merchant doesn't have to maintain a set of links to existing private financial networks.

The consumer enters payment and other information at the merchant's Web site. After confirming the transaction with the consumer, the merchant forwards the signed and encrypted information to the CyberCash server. CyberCash decrypts, validates and breaks the message into components. The transaction is reformatted according to traditional credit-card message formats and sent to the issuing bank via the POS network. The approval or denial code is forwarded to the merchant's Web site, and the consumer is informed as to the acceptance or rejection of the sale.

The CyberCash protocol is both modular and flexible. It involves three parties: the consumer's wallet, the merchant's e-commerce package and the CyberCash server. Separate sets of messages are defined for CyberCash to consumer (CH*) and CyberCash to merchant (CM*). This flexible method lets the merchants accept payments from consumers who have selected the CyberCash wallet or, potentially, provide their own HTML forms secured by SSL. ("CyberCash Message Flows," at right, lists the possible messages.) CyberCash encrypts all data at the message level, using 1,024-bit RSA and 56-bit DES encryption. When using the wallet, the merchant does not have to see the buyer's payment details.

It's important to note that the messages exchanged by CyberCash occur at the application layer. The underlying layers consider the messages as user data payload. You won't receive support for analyzing application protocols from a protocol analyzer; rather, look to the application vendor to supply robust APIs, logging and diagnostics.

CyberCash application messages are text blocks. Similar to the concept of CGI POST data or e-mail header information, data fields are perceived as value pairs. All messages consist of a header, which denotes message type and version; a transparent component, which contains data known to all parties; an opaque portion, which includes financial, privacy-protected information (communication exists between the wallet and CyberCash server); and a trailer, which marks the end of the message and includes a check value. Logs of these messages provide the nonrepudiation service that SSL lacks.

To develop e-commerce software, you need to familiarize yourself with a variety of protocols, security schemes and message formats. Even systems integrators and developers who don't delve into a wire's bits and bytes must rely on their understanding of these protocols to configure, support and use e-commerce APIs.

Brian Walsh is the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this article to him at brian@bwalsh.com