MDN Usage in AS2

B2B (Business to Business) is an integration term used to describe the sending and receiving of business messages between business partners.  When the business messages are being sent over the internet via HTTP or SMTP, it is critical to business operators to know that the messages were transmitted successfully to the right party.   In order to give assurance to the business operators, specific B2B transmission standards have been developed.  We call these standards "Message Exchange Standards".  These include AS1, AS2, AS4, ebMS and RNIF, to name a few.  AS2 is a very common standard for EDI messaging.  It is important for everyone using the standard to do so in the same way, or else inter-operation becomes very difficult or impossible.  Here is a diagram showing a typical EDI interaction over AS2 between two fictitious partners named OracleServices and MarketInc.

Note that the MDN's are used to acknowledge the receipt of both the 850 and the 997 documents.

AS2 provides features such as Non-Repudiation of Origin, Non-Repudiation of Receipt, and Message Protection.  When sending a message, the sender includes a digital signature, and the receiver replies with an acknowledgement called an MDN (Message Disposition Notification) that includes the receiver's digital signature.  Because each message is signed digitally, the receiver can be sure that original message has really been sent by the sender, and that the message has not been tampered with, which we call Non-Repudiation of Origin.  When the receiver replies with the signed MDN, the sender can be sure that the receiver obtained the message successfully, and that it was the correct receiver, which we call Non-Repudiation of Receipt.  When message encryption is turned on, then the message can be protected in flight because it can only be decrypted by the receiver.

The best analogy to help people understand this is a shipping example.  If you ship an overnight package from your office to a business partner's office, which contains a sensitive and time critical document like an agreement that you've signed, you want to make sure that it is delivered on time and to the right place.  You can ask for extra services from the shipping company such as an email delivery notification and a signature upon receipt.   The email notification is much like an MDN.  The signature you put on the agreement is like the digital signature of the sender, and the signature that the shipping company collects is like the digital signature of the receiver.  Everyone is confident that the document was delivered correctly and is in fact the document that it is supposed to be.

The scope of the MDN is as follows:

• Acknowledge the successful transmission of the message (the transport)
• Verify the identity of the sender through the digital signature
  
• Verify the integrity of the message by comparing a hash value produced by the sender and encrypted in the digital signature with the hash value of the decrypted received message
  

Sometimes, people attempt to include more into the scope of an MDN, which causes confusion and replicates functionality provided by other B2B Standards.  These functions are NOT in scope for an MDN:

• Message Validation - (e.g. EDI Validation or XML Schema validation)
  
• Successful processing of the message through the entire back end application process (e.g. PO Acknowledgement)

When Message Validation or Application Acknowledgements are attempted to be added to the MDN, it can cause significant delays to the MDN delivery, and can cause confusion at the sender, because the sender will not know if the negative Acknowledgment is because of message corruption (message integrity check), or because of a syntax violation. Most users of the message exchange standards and B2B standards will want the MDN to quickly validate the transmission of the message, and would expect a 997 or CONTRL message as a functional acknowledgment for the message syntax validation.

In the case of XML standards, some provide equivalent document definitions for Functional Acknowledgments, such as the ConfirmBOD in OAGIS.  If a custom XML document is being used, then a mutually agreed upon XML document should also be developed to transmit the successful parsing of the XML document, if that functionality is desired.  If there are other exception handling processes developed by the receiver, this may not be necessary, as long as the sender can be notified somehow that there was a syntax violation through email, phone or fax.  Of course, if you are doing a B2B interaction, it is best to try to take advantage of the existing B2B standards that are available so that you don't have to reinvent the wheel.

AS2 and other Message Exchange Standards provide an excellent mechanism to securely transfer business documents over the Internet.  Be careful not to mix the purpose of Transport standards with Data Standards though, and you can inter-operate with your partners successfully.