What is AS2?

AS2 is the abbreviation for "Applicability Statement 2 (AS2)" a frequently used communication protocol for electronic data interchange (EDI).

The communication protocol sends EDI files via the Internet (HTTP). The special feature of the communication protocol AS2 is that the protocol has acknowledgements of receipt (the so-called MDN: Message disposition notification). They serve as proof that the files have been delivered properly and on time.

In addition, the AS2 protocol offers the possibility to sign or encrypt files. The communication standard AS2 has existed since 1997 (at that time still under the name "HTTP Transport for Secure EDI"), since 2005 it has been renamed AS2 in RFC 4130.

The above features make AS2 one of the safest and most reliable EDI transmission standards. In addition, the protocol is inexpensive and easy to use (unlike VAN such as the X400 network). Learn more about AS2 and its benefits in our blog post: "Why AS2 is the optimal EDI communication protocol".

How does AS2 work?

In order to receive EDI messages via AS2, you first need AS2 software (AS2 client & AS2 server), an Internet connection and possibly a certificate. So that your partners can send you files via AS2, in the first step you need a running AS2 server that listens to a public IP address and a port that can be reached from outside and reacts to incoming AS2 connections (for example: menten.com:4080).

Next, you need the connection information of the AS2 partner from whom you want to receive files.

This includes the following Information:

• Host/IP address
• Port
• AS2-FROM or AS2-TO (send, receive address)
• Signature algorithm (if you want to sign)
• Encryption algorithm (if encryption is required)
• Certificate (if encrypted and/or signed)

After you have entered the partner's information in your AS2 software and sent your configuration settings to your partner in return, you can start exchanging EDI files via AS2.

The exact procedure of an AS2 transaction with signature and encryption is shown in the following diagram "AS2-communication workflow with i‑effect^®".

Description of the process (Encrypted and Signed):

1. The file to be sent is signed using the private key of system A and then encrypted using the certificate (public key) of system B. The file is then encrypted using the private key of system A.
2. The signed and encrypted file - now unreadable to third parties - is now sent via HTTP or HTTPS. (If the header of the message - i.e. the information who sends whom something to whom - is to be protected against access by third parties, then HTTPS should definitely be used here - this is the only way to encrypt the communication channel itself).
3. After the file has been received by system B, the file is decrypted using its own private key (system B). In case of problems decrypting the message, a negative MDN will be sent with the message "Error decrypting" (synchronous or asynchronous depending on configuration).
4. If the file has been successfully decrypted, the signature will now be verified (message integrity). Also in this case a negative MDN is sent to system A in case of an error: "Signature error" (depending on configuration synchronous or asynchronous).
5. If both the file was successfully decrypted and the signature check was successful, an MDN with the indicator of successful receipt is sent at the end.

Advantages of AS2

• Simple setup
• Inviolability & authorship of the data can be guaranteed (signature)
• Data security (by encrypting the transport route and the file)
• Transfer of time limit rights by proof of delivery in the form of an acknowledgement of receipt (MDN). No technical protocols necessary.
• As a rule, there are no costs for the transfer of the files themselves, since communication takes place via the Internet
• Wide distribution and acceptance of AS2 (e.g. EDI@Energy, AK-Handel, etc.)

What does an AS2 header look like?

The AS2 header serves as an envelope when sending AS2 messages and contains some information about the message itself and about the sender or recipient.

The following example shows the Header of a session in which the file "helloworld.txt" is sent:

The following example shows the Header to a sent MDN:

What does an MDN look like?

MDN messages are sent in response to a received message. If an error occurs, they contain error messages explaining the message was not received correctly. If successful, the MDNs are used as proof of delivery.

A "normal" MDN thus unencrypted and unsigned looks in something like this:

What are asynchronous and synchronous MDNs?

The receipt receipts, the so-called MDNs, can be transmitted either synchron (in the same session or connection) or asynchron (in any other session).

Synchronous MDNs send receipts immediately after receiving and verifying the message. In practice, synchronous MDN messages are often sent, as this is more manageable.

However, there are also applications in which asynchronous MDNs make sense. For example, if you send larger files. Here it can happen that a session can run into a timeout by checking the signature and decrypting the files. This can be prevented by using asynchronous MDN messages, since the client does not have to wait in the same connection. Besides the timeout "problem" there is also an approach for IT infrastructure reasons to use different addresses for receiving messages and sending MDN messages.