AS2

For the programming language sometimes abbreviated to AS2, see ActionScript § ActionScript 2.0.

AS2 (Applicability Statement 2) is a specification on how to transport structured business-to-business data securely and reliably over the Internet. Security is achieved by using digital certificates and encryption.

Background

AS2 was created in 2002 by the IETF to replace AS1, which they created in the early 1990s.

The adoption of AS2 grew rapidly throughout the early 2000s because major players in the retail and fast-moving consumer goods industries championed AS2. Walmart was the first major retailer to require its suppliers to use the AS2 protocol instead of relying on dial-up modems for ordering goods. Amazon, Target, Lowe's, Bed, Bath, & Beyond and thousands of others followed suit. Many other industries use the AS2 protocol, including healthcare, as AS2 meets legal HIPAA requirements.

In some cases, AS2 is a way to bypass expensive value-added networks previously used for data interchange.

How AS2 protocol works

Technical overview

AS2 is specified in RFC 4130, and is based on HTTP and S/MIME. It was the second AS protocol developed and uses the same signing, encryption and MDN (as defined by RFC3798) conventions used in the original AS1 protocol introduced in the late 1990s by IETF. In other words:

• Files are encoded as "attachments" in a standardized S/MIME message (an AS2 message). AS2 does not specify the contents of the files. Usually, the file contents are in a standardized format that is separately agreed upon, such as XML or EDIFACT.
• AS2 messages are always sent using the HTTP or HTTPS protocol (Secure Sockets Layer — also known as SSL — is implied by HTTPS) and usually use the "POST" method (use of "GET" is rare).
• Messages can be signed, but do not have to be.
• Messages can be encrypted, but do not have to be.
• Messages may request a Message Disposition Notification (MDN) back if all went well, but do not have to request such a message.
• If the original AS2 message requested an MDN:
  • Upon the receipt of the message and its successful decryption or signature validation (as necessary) a "success" MDN will be sent back to the original sender. This MDN is typically signed but never encrypted (unless temporarily encrypted in transit via HTTPS).
  • Upon the receipt and successful verification of the signature on the MDN, the original sender will "know" that the recipient got their message (this provides the "Non-repudiation" element of AS2).
  • If there are any problems receiving or interpreting the original AS2 message, a "failed" MDN may be sent back. However, part of the AS2 protocol states that the client must treat a lack of an MDN as a failure as well, so some AS2 receivers will not return an MDN in this case.

Like any other AS file transfer, AS2 file transfers typically require both sides of the exchange to trade X.509 certificates and specific "trading partner" names before any transfers can take place. AS2 trading partner names can usually be any valid phrase.

MDN options

Unlike AS1 or AS3 file transfers, AS2 file transfers offer several "MDN return" options instead of the traditional options of "yes" or "no". Specifically, the choices are:

AS2 w/ "Sync" MDNs

Return Synchronous MDN via HTTP(S) ("AS2 Sync") - This popular option allows AS2 MDNs to be returned to AS2 message sender clients over the same HTTP connection they used to send the original message. This "MDN while you wait" capability makes "AS2 Sync" transfers the fastest of any type of AS file transfer, but it also keeps this flavor of MDN requests from being used with large files (which may time out in low-bandwidth situations).

AS2 w/ "ASync" MDNs

Return Asynchronous MDN via HTTP(S) (a.k.a. "AS2 Async") - This popular option allows AS2 MDNs to be returned to the AS2 message sender's server later over a different HTTP connection. This flavor of MDN request is usually used if large files are involved or if your trading partner's AS2 server has poor Internet service.

AS2 w/ "Email" MDNs

Return (Asynchronous) MDN via Email - This rarely used option allows AS2 MDNs to be returned to AS2 message senders via email rather than HTTP. Otherwise, it is similar to "AS2 Async (HTTP)".

AS2 w/ No MDNs

Do not return MDN - This option works like it does in any other AS protocol: the receiver of an AS2 message with this option set simply does not try to return an MDN to the AS2 message sender.

Filename preservation

AS2 filename preservation feature will be used to communicate the filename to the trading partner. The banking industry relies on filenames being communicated between trading partners. AS2 vendors are currently certifying that implementation of filename communication conforms to the standard and is interoperable. There are two profiles for filename preservation being optionally tested under AS2 testing:

• Filename preservation without MDN responses
• Filename preservation with an associated MDN response certification

Walmart recommends contacting Drummond Group, LLC for more information on EDIINT AS2, or for a list of interoperable-testing AS2 software providers.

Benefits

For many businesses, the use of AS2 and electronic data interchange (EDI) is not a choice so much as it is a requirement of doing business with a large customer or partner. That said, AS2 is a universal protocol that has benefits, from both business and technology vantage points.

Business case

• Cut costs by using the web for EDI file transfers, AS2 reduces the cost of transactions from expensive VANs.
• Extend EDI to more partners; with lower costs and universal web connectivity, AS2 allows organizations to implement EDI with partners worldwide that have little EDI infrastructure.
• Save time by eliminating the need to manually process orders.
• Eliminate errors by turning manual processes into automated processes.
• Universal solution — AS2 is established and tested, so no one has to re-invent the wheel.

Technological advantages

• Leverage the web: if an organization can share data securely via the web, they already have much of the infrastructure for AS2.
• Unlimited EDI data — there are no practical limitations on transaction sizes via the web, and AS2 includes features for managing large transfers.
• Payload Agnostic — AS2 can be used to transport any type of document. While EDI X12, EDIFACT and XML are common, any mutually agreed-upon format may be transferred.

See also

• AS1
• AS3
• AS4

External links

• RFC 4130 - AS2 specification
• AS2: Part 1 - What Is It? AS2 series by Loren Data Corp.
• AS2: Part 2 - Best Practices AS2 series by Loren Data Corp.
• AS2: Part 3 - Certificates AS2 series by Loren Data Corp.