Common Combinations for Security, Transport, and Packaging

The biggest news in this area in the last part of 2002 was that Wal-Mart decided to move from doing direct dial-up for EDI to Internet-based transport using the EDI over the Internet ( EDIINT ) standard developed by the Internet Engineering Task Force ( IETF ). There are two flavors of EDIINT, one based on SMTP (called AS1 for Applicability Statement 1) and the other based on HTTP (called AS2 ). Both use S/MIME. Wal-Mart is requiring that its vendors use AS2. Notice two important things about this development: (1) the choice of the relatively mature EDIINT using S/MIME for packaging and encryption, and (2) the decision to still use EDI and not XML. EDIINT can be used for payloads other than EDI, and there are several software packages available for it. More than likely, you can expect to be asked to use it in the next several years .

Here are a couple other approaches I've seen.

• Secure HTTP : Session-based security using HTTP post and get and X.509 certificates. The U.S. Immigration and Naturalization Service is using this approach for schools reporting information on foreign students. One document is transmitted at a time, so there isn't a packaging issue.

• Secure FTP : Session-based security using FTP and session-negotiated encryption. The Student Aid Internet Gateway of the U.S. Department of Education is using this approach for transmitting student loan data. Proprietary software is used for packaging and compression.

There are a few very easy ways to package and transport XML if your requirements are not very stringent. At the inaugural ebXML Work Group meeting in November 1999, the Business Application Software Developers Association (BASDA) demonstrated a very simple, workable approach with small business “oriented desktop business applications. This approach basically involved exporting XML documents to disk files, attaching them to e-mail messages using common e-mail clients , and then sending them over the public Internet in the clear. The recipient detached the XML document from the message, imported it into the business application where it was held in a suspense state for review, and then released it after review.

If you don't have great concerns about confidentiality or authentication, an approach like BASDA's could work just as well for you as it did in the demo. However, if you are concerned about these security aspects, many common e-mail clients allow you to attach an XML document to an e-mail message, then encrypt them both with S/MIME. The recipient can then decrypt and authenticate both. There are, however, a few disadvantages to this approach. One is that most e-mail clients bundle the e-mail message body and any attachments together as one S/MIME attachment. This might not be a problem, but with this method you can't independently apply a digital signature to an XML document. In addition, some e-mail clients (particularly automated ones in large companies) may not support this approach. It is primarily person-to-person rather than fully automated, which comes with its own set of problems. However, if you're part of a small company and want to exchange XML documents with other small companies (or even with people in large companies who will support doing this method), this is a cheap, easy solution for packaging and transport that uses software you probably already own.