![]() Corporate.Net Feature Article Signed, Sealed & Delivered: CommerceNet Test Results How It Works
The data flow of EDI over the Internet is illustrated in "EDIINT Data Flow" (preceding page). A purchase order is created within the company's internal financial systems component. It is passed to the EDI translator for reformatting into a standard format, such as those described in X12 or the United Nation's Rules for Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT). The reformatted PO is then relayed to the communications software, which may encrypt the PO before signing it and sending it via IETF protocols to its destination.
In testing this implementation of security for EDI, CommerceNet found--as did the vendors that ran the interoperability tests--that the communications system remains completely independent of the EDI translator. As a result, after the first few tests, most vendors tested only the communications interface, since EDI translators have proven themselves to be interoperable over different communication stacks. According to the EDIINT workgroup, making secure EDI available worldwide means supporting two parallel, yet competing, security architectures: Secure Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP). The latter, which historically has been freeware, offers strong international encryption and is entrenched in the academic and Internet communities. While S/MIME is the main focus of most U.S. software companies, this architecture does not support strong encryption beyond U.S. borders because of federal export laws. Hence, the IETF's EDIINT recommendations support both of these standards. Because MIME is the basis for packaging, the data structures can also be used to transport secure EDI via FTP, the Web or direct TCP/IP. S/MIME and PGP solve most of the identified security issues: encryption, digital signature, integrity and certificate management. Neither PGP nor S/MIME addresses the precaution of signed receipts, however, so the EDIINT recommendations implement a signed receipt format. A signed receipt is what the recipient of a message returns to the sender to verify that the message was delivered properly. The Interoperability Methodology Although interoperability is the objective, we know that it is impossible to exhaustively test and verify interoperability. Therefore, the CommerceNet Interoperability Pilot zeroed in on the primary processing routes--those most likely to be used for business-to-business exchanges. The pilot was launched in October 1996 with 10 vendors, divided into two groups. Over the next nine months, each group ran the interoperability tests first among their own members and then between the groups. The pilot identified many initial interoperability problems with the implementations, but these were fixed and testing continued. The testing process fell into three phases, eac h building upon the results of the earlier phases. These were general EDI exchanges over the Internet using MIME as the package; exchanging encrypted, signed or signed-then-encrypted data; and signed receipts. The EDI test data is derived from two standards: ANSI X12 and EDIFACT. X12 is the North American EDI standard, and it defines many more transactions than EDIFACT, the worldwide standard. For each test, CommerceNet used one of six sets of test data. Some contained non-7-bit data (Internet-based e-mail systems are usually 7-bit, thus requiring translation to a 7-bit format for transmission); some were very large data sets; and others were composed of more than just EDI data, such as a very large Microsoft Word file. The test data was mixed among the participants, with some using an EDIFACT-based PO and others using a PO from X12. After the exchange was completed, the data was compared to the reference data to ensure that it had been transported without modification. EDDIINT Interoperability Test Phases and Sample EDIINT Interoperability Test Internet Rx By Todd Tannenbaum Updated September 8, 1997 |


How It Works
The data flow of EDI over the Internet is illustrated in "EDIINT Data Flow" (preceding page). A purchase order is created within the company's internal financial systems component. It is passed to the EDI translator for reformatting into a standard format, such as those described in X12 or the United Nation's Rules for Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT). The reformatted PO is then relayed to the communications software, which may encrypt the PO before signing it and sending it via IETF protocols to its destination.













