This last year the EDI community has shown a substantial increasing interest in AS2. But what exactly is AS2? This is the first in a multipart series to examine AS2 and what it means going forward to the EDI industry. If you want all the historical and technical information on AS2, then I suggest you Google AS2. This series is about the practical uses and not to bore you with (too many) details.
AS2 is a communication protocol for transferring files from one system to another. (FTP is another example of a protocol used for transferring files.) While it was developed with EDI in mind, it can be used to transport data of any type from system to system.
To send and receive AS2 one must have AS2 software, which acts as both a client (for sending) and a server (for receiving). This is really no different than to need for an FTP client and FTP server when using that protocol. There are multiple AS2 software packages on the market (some even free) and a number of hosted offerings. Each offers different levels of automation, integration and licensing requirements; but what they all have in common is interoperability: any AS2 package should be able to exchange data with any other AS2 package.
When all configured properly, this is what happens in the typical AS2 file transfer:
- The file is received locally by the sender’s AS2 system;
- The receiver system is identified;
- The sender encrypts the file with the receiver’s public key;
- The sender signs the file with the sender’s private key;
- The sender transmits the whole message to the receiver’s AS2 server;
- The receiver identifies the sender by AS2 ID;
- The receiver validates the file with the sender’s public key;
- The receiver decrypts the file with the receiver’s private key;
- The receiver sends an MDN (message disposition notices) back to the sender, encrypted and signed (reverse of the keys above), acknowledging the successful receipt of the file;
- The sender verifies the MDN and the transfer is complete.
Here are a few key features of AS2:
AS2 is HTTP-based. That means it runs as a web server and web client using the HTTP protocol. What differentiates this from using a standard web server is the formatting of the message that is transferred. Many AS2 applications run on top of a standard web server. It can also run over HTTPS (SSL).
Messages sent over AS2 have a specific format, which is handled by the AS2 software. Both successful and unsuccessful transfers receive an MDN (message disposition notice) if requested, allowing the sender to know if the transfer succeeded. MDNs are not proof that the data is valid, but it does confirm the other side received the payload.
Each AS2 “system” has a unique identifier called the AS2 System Identifier (or AS2 ID for short). The AS2 ID must be comprised of 1 to 128 printable ASCII characters and is case-sensitive. This AS2 ID identifies the sender and receiver, and which certificates should be used. It also allows multiple servers to be used for the same AS2 system, for load balancing and for redundancy. There is currently no registrar for AS2 IDs and no guarantee that they are unique from all other systems. It is up to the implementer to make sure they are unique.
AS2 incorporates encryption and digital signatures. Once encrypted, only the intended recipient can read the data, and once signed, there is a high confidence in who actually sent the data. AS2 uses public and private keys and certificates for encrypting and signing messages. The biggest challenge is managing all the certificates and keeping them up to date.
In the early days (2005) the Drummond Group and its certification were critical to getting all the new AS2 developers on board and adhering to the standard. Now the need for that is less as there is plenty of existing AS2 to test new systems against. Either they work or they don’t.
The bigger issue now is in all the various ways “certified” software is implemented by end users, causing all sorts of configuration issues and problems.
Personally, I am an AS2 convert. When properly implemented, I think it is a superb system for reliably and securely transferring files between two systems. At Loren Data we have now incorporated AS2 as a core component of our ECGrid network with full ECGridOS API integration, and it is now our preferred communication protocol.
The next article in this series will address that and provide a set of AS2 Best Practices, based on the practical experience of setting up countless AS2 connections to our own ECGrid system.
Loren Data Corp.