Introduction to AS2

(Available as an optional module in EFT) AS2 is used to exchange structured business data securely using the HTTP or HTTP/S protocol. Any type of data can be exchanged using AS2, including traditional EDI messages, XML, flat files, spreadsheets, and CAD/CAM data. AS2 is not concerned with the content or validity of the data being sent, but only with the connection and the secure, reliable exchange of data. Data security is achieved using S/MIME through signing and/or encryption.

EDI messages were originally send from an FTP client to an FTP server. The message was not encrypted, and there were no guarantees of receipt or whether it was even sent. With the AS2 protocol, you need a server at both ends of the transmission, the message is encrypted/hashed (over HTTPS), there is verification of who sent/received the message, and data integrity is ensured.

AS2 offers distinct advantages over FTP or plain HTTP, including increased verification and security with receipts and digital signatures. Its transactions and acknowledgements occur in real time, increasing the efficiency of document (data) exchanges. AS2 is also referred to as EDIINT AS2 (EDI over the Internet AS2). Many organizations are migrating to this protocol to reduce costs, and requiring their trading partners to switch to the AS2 protocol. Sending encrypted payloads over HTTPS ensures that only the sender and receiver can view the data exchanged. The use of a hash algorithm ensures data integrity by detecting whether the document was altered during transmission.

The basic structure of an AS2 message can be compared to an envelope that contains a MIME-formatted message inside an HTTP message with AS2 headers. The Message Disposition Notification (MDN) or receipt is returned in the HTTP response message body or in a new message to an alternate URL specified by the originator. This request/reply transactional interchange can provide secure, reliable, and authenticated transport for data using HTTP as a transfer protocol. The security protocols and structures used also support auditable records of these document data transmissions, acknowledgements, and authentication. In a secure message exchange, one organization sends a signed and encrypted message to another organization and requests a signed receipt, and later the receiving organization returns the signed receipt to the sending organization.

Non-repudiation of receipt (NRR) is a legal event that occurs only when the original sender has verified the signed receipt returned from the recipient of the message, and has verified that the returned message integrity check (MIC) inside the MDN matches the previously recorded value for the original message. That is, the sender of the message obtains undeniable proof that the recipient received the message and that the message was not altered in transit. NRR is established when both the original message and the receipt use digital signatures.

EFT uses HTTPS to exchange data with AS2-ready servers and clients. Extended HTTP header information outlines how data should be handled and whether signed or unsigned receipts are required.

EFT also validates data integrity upon receipt and requests acknowledgment or message disposition notification (MDN) upon completion of outbound transfers. For technical details of AS2, refer to RFC 4130.