AS2: The Complete Guide
In this guide to the AS2 protocol, we walk you through a complete definition of AS2 and provide everything you need to know to get started with it, including:
- What is AS2?
- Background on AS2
- Benefits of AS2
- How AS2 Works
- AS2 Implementation
- AS2 vs. AS1, AS3 & AS4
This guide is for anyone who needs to learn or implement AS2 for B2B document exchange.
What is AS2?
AS2 stands for Applicability Statement 2 and is a B2B messaging protocol used to transmit Electronic Data Interchange (EDI) documents from one organization to another.
AS2 is a universal method for transporting data used by millions of businesses worldwide, including most major retailers, such as Amazon and Walmart. AS2 specificies how to securely transport data via the Internet using HTTP/S (hypertext transport protocol secure) - the same protocol nearly every website uses. AS2 is a second-generation EDI protocol, created by the Internet Engineering Task Force (IETF) in 2002 to replace AS1, which uses email protocols for secure data transfers.
Drummond Certification
AS2 is backed by the Drummond Group, an organization that certifies AS2 Software - if you and your trading partner use Drummond-Certified AS2 solutions, they can work together to exchange EDI documents.
Unlike software for many other file transfer protocols, AS2 software is tested for interoperability by Drummond-Certified AS2 vendors twice per year against a battery of security profiles, ensuring any interoperability issues are found and resolved during testing and not in your production environment. If you choose a non-Drummond-certified AS2 solution, you may encounter issues with your trading partners due to a lack of interoperability testing.
Technology and Features
AS2 enables secure data transmission over the Internet using HTTP/S and is an easier protocol to adopt than many others because of the ubiquity of Internet access. It involves two computers, a client and a server, connecting online in a point-to-point manner. AS2 is an open standard for secure, payload-agnostic exchange of B2B documents.
Security
AS2 is a protocol designed with three core features:
- Security: Sensitive data is protected in AS2 through the transport layer via SSL or in the payload layer through S/MIME. AS2 uses the S/MIME protocol to wrap EDI data in a secure "envelope" and send it over the web.
- Integrity: The identity of the sender and the integrity of the payload are ensured because the message is signed using digital certificates. There is also encryption to ensure only the correct party receives EDI messages and no one can intercept them while in transit.
- Non-Repudiation: The receiver of the data returns a signed message containing a Message Integrity Check (MIC) calculated over the payload.
Who Uses It?
Walmart famously championed EDI via AS2 and has driven its mass adoption within the broader retail industry in particular. AS2 is the de facto standard for EDI transactions in the U.S and is also commonly used for healthcare and government message exchanges.
More Background on AS2: a (Very) Brief History
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 consumer-packaged goods (CPG) 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.
They showed they could cut costs and achieve near real-time EDI communication with direct AS2 EDI, bypassing expensive, legacy value-added networks (VANs). Now, many other industries use the AS2 protocol, including healthcare, as AS2 meets legal HIPAA requirements.
Benefits of AS2
So why use AS2? For many businesses, the use of AS2 and EDI is not a choice so much as it is a directive from a larger customer or partner. That said, AS2 is a universal protocol that provides many benefits, from both business and technology vantage points. For many companies, EDI through AS2 is well worth the investment.
Business Case
- Cut costs by using the web for EDI file transfers, AS2 reduces the cost of transactions from expensive VANs and traditional EDI.
- Extend EDI to more partners; with lower costs and universal web connectivity, AS2 allows you 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 reinvent the wheel. For millions of companies, that's the reason it trumps all other EDI protocols.
Technological Advantages
- Leverage the web: if you can share data securely via the web, you already have much of the infrastructure for AS2.
- Unlimited EDI data - no practical limitations on transaction sizes via the web, and AS2 includes features explicitly for managing large transfers.
- 24/7 connectivity with minimal downtime - if your server stays up, your AS2 stays up.
- Flexibility - the HTTP/S and S/MIME signing and encryption technologies in AS2, are widely used and regularly maintained
- 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.
How AS2 Works
So, how does AS2 work? It follows a fairly straightforward process. AS2 provides an "envelope" for EDI data to send it securely via the web (and other TCP/IP- based networks) using HTTP/S.
Process
The sender transmits messages using AS2 software:
1. EDI Document Preparation
Documents are prepared in a standard EDI format to send over AS2 (though AS2 can send documents in any format)
2. AS2 Packaging
The document is transformed to send via AS2. Documents sent via AS2 can (but don't always have to) undergo three types of transformation:
- Compression: The document may be compressed using a compression algorithm to reduce the size of the transported data
- Signature: The data is typically signed using the private key of the sender to ensure the sender's identity as the creator of the document
- Encryption: The data is typically encrypted using the receiver's public encryption key, so only the proper recipient will be able to extract the document. AS2 wraps the message in a secure envelope using the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol.
3. Message Delivery
The message is securely transmitted over HTTP/S using file transmission software or services.
4. AS2 Unpackaging
The receiving server listens for messages addressed to it, always staying online (if the recipient's server is offline when a message is sent, the sender will receive an error). The receiver of the prepared document then unpackages to retrieve the EDI document. If the data was encrypted, the prepared document is decrypted using the receiver's private key. If it was signed, the signature on the document is verified using the sender's public key to verify the sender's identity. If the document was compressed, it's decompressed.
5. EDI Processing
The AS2 receiver passes the unpackaged EDI document to any back-end process that handles the data to perform any additional business logic.
6. MDN Reply (Recipient)
The receiving organization uses AS2 or EDI software to extract the message and send message confirmation receipts to the sender.
7. MDN Processing (Sender)
The sender validates the receipt signature and compares the returned content message integrity check (MIC) against the one originally calculated
Layers of Receipt and Confirmation
To ensure every message reaches its destination, there are four layers of receipt acknowledgements available in EDI. Three are common to any protocol that facilitates document exchange, and AS2 adds the fourth.
- Communication Status: confirms data is received at a network level
- MDN: message disposition notifications (MDNs) confirm the message was successfully extracted from the envelope and that the payload received matches the payload transferred from the client. (added by AS2)
- Functional Acknowledgement: confirms a valid message is received by the e-commerce application(e.g. the EDI envelope was opened and contained a valid EDI document). Also known as 997/999 (X12) or CONTRL (EDIFACT).
- Business Acknowledgement: confirms the content of the message and that it has been dealt with in an appropriate way (for example, a purchase order acknowledgement agrees to fulfill the orders made in a purchase order)
Some key points:
- AS2 is most commonly used for EDI transactions but can handle any document type
- AS2 envelopes may contain another envelope (e.g. ANSI X12 EDI) that hold the actual business document
- Like traditional EDI, you can use tools to extract data from internal systems and translate it into the appropriate standard before sending
- You can then process the data you send and receive in the same way
- To speed up transmissions, AS2 supports compression to decrease the size of each message
AS2 Implementation: Key Components & Decisions
Direct AS2 EDI vs. VAN
You can use AS2 with direct EDI for each trading partner or use a Value Added Network (VAN).
In direct EDI, also known as point-to-point EDI, you establish a connection with each partner using an agreed-upon protocol, in this case AS2. Ownership of the system and management of its parts and connections is maintained by the parties in communication (although you may host your environment in a cloud environment, such as Amazon EC2).
VANs act as middlemen, translating EDI messages between protocols and partners, enabling you to use your own, single protocol no matter which protocol your partners use - for example, if you only use AS2 but have European partners using OFTP2 and AS4 in addition to AS2.
VANs can offer hosted management of your EDI documents, visualization of your data, and extended reporting - at a price. VANs operate as a continued service, and while they may reduce your starting costs, they charge a fee for every single document (or even line item) they process.
Traditionally, VANs were the only option available for smaller businesses that lack the EDI resources or knowledge to support EDI themselves, but as EDI technology has matured and EDI software has emerged, direct EDI is used more and more. VANs usually reduce initial setup costs, but they charge a fee for every single document, or even line item, they process. Unless you are processing a small number of documents, you can save money in time with direct EDI.
There are other considerations as well, such as control over your setup, partner requirements, security and more.
Direct EDI
VAN EDI
Firewall Security
Using AS2, you send and receive business transactions over the Internet. Like you'd lock your door, you'll want to secure this doorway to the web, and firewalls are the most common approach. The two main options are to:
- Have each partner send AS2 using a dedicated port, or network address, that only receives transactions from their IP address or a specific source
- Use a demilitarized zone (DMZ) - all AS2 traffic comes in on one port, and the computer running AS2 only talks to computers in your organization. You can think of this as a double-door airlock that isolates AS2 traffic from your computers, eliminating the need for specific security solutions with each vendor
HTTP vs. HTTPS
AS2 uses the hypertext transmission protocol (HTTP), which can be specifically secured with an SSL certificate. Most websites have moved or are moving from traditional HTTP to HTTPS, so HTTPS is becoming the standard.
Digital Certificates
At ArcESB, we recommend encrypting all AS2 EDI transactions using digital certificates. They verify the identity of each trading partner for every transaction. Only trading partners with a secure private key can receive and access the AS2 EDI transactions, preventing data from being intercepted in transit.
You have two primary options for generating digital certificates:
- Enlist a Certificate Authority (CA), such as Envision or Verisign, to manage the process, verify certificates and revoke expired certificates
- Use an EDI application that comes with built-in capabilities to "self-generate" digital certificates - ArcESB comes with full built-in certificate capabilities
Unless the security policy of your trading partner dictates otherwise, the most common approach is to purchase an SSL certificate from a CA if you're hosting SSL connections and to use self-signed certificates for signing and encryption. An SSL certificate from a trusted CA validates your identity to an anonymous visitor on your web server, but self-signed certificates are more common in AS2, as the existing trust relationship between the parties in communication is already established (and it's free to create certificates).
Encryption
By using the recipient's public certificate, the AS2 message contents are encrypted to secure the data. Only the recipient will be able to decrypt the contents, using their private certificate.
To encrypt your data as you transmit it via AS2, the EDI software for both you and your partner must use and support the same encryption algorithm. Popular options include:
- 168 Bit Triple DES (3DES), which is the default
- AES (not universally adopted)
Signature Algorithm
You and your trading partners can sign transactions to certify their authenticity. AS2 supports the following options:
- No signature - not recommended, since this eliminates authentication
- SHA-1
- SHA-2 (also called SHA-256) - a replacement for SHA-1 launched in 2018 that is more common but not yet universally adopted
The AS2 standard now recommends using SHA-2 but you may also need to support both SHA-1 for use with different trading partners.
Signing messages is an essential aspect of AS2 transmissions. Signatures prove the sender's identity and contain a MIC (Message Integrity Check), calculated using the SHA-1 or SHA-2 algorithm. When a receiver verifies a signature, this MIC is compared to a MIC that is calculated over the body of the signed message by the recipient. If the MIC sent in the signature and calculated over the payload match, the sender can be confident there was no tampering of the data.
Receipts (MDNs) and Non-Repudiation
Receipts, or message disposition notifications (MDNs), confirm that trading partners receive a document, providing "non-repudiation," or non-deniability of receipt. There are five options for handling receipts, including:
- No receipts - a bad choice that provides zero audit trail and can lead to false positives for transmission. The security equivalent or removing the batteries from a smoke detector.
- Plain receipts - unsigned receipts returned immediately to the sender to show a message receipt. Also a bad choice, as it is subject to impersonation.
- Signed receipt - returned immediately and signed, providing the strongest audit trail
- Asynchronous plain receipt - a plain receipt that's sent later, not immediately
- Asynchronous signed receipt - a signed receipt that's sent later, not immediately. This is useful in situations where the message is larger, and thus the sender may not wish to leave the initial connection open while waiting for an MDN that takes longer to generate is returned.
The sender specifies the form of receipt the receiver must send back, so you need to make sure your software supports all five options, as each partner may require different receipts.
Additionally, the MDN receipt contains the MIC calculated over the received payload of the initial transmission. When the original sender validates the MDN, this MIC is compared against the MIC that was originally calculated over the AS2 transmission, so the sender receives a guarantee that the payload was received as packaged. The use of signatures on the message and receipt creates a Non-Repudiation of Receipt (NRR) event, considered legal proof of delivery.
Documents and Standards
In addition to properly implementing the AS2 protocol, you will need to determine both the EDI standards and documents you'll exchange with each of your partners - whether it be an EDIFACT INVOIC, an X12 850 Purchase Order, a HIPAA EDI Patient Admit or anything else.
Learn more about EDI Standards
AS2 and Other Types of EDI Protocols
Not sure if AS2 is right for you? Need to implement more than one protocol for various trading partners? Here we cover all the AS protocols, and we introduce all the major EDI messaging protocols in our full protocols guide.
AS2 vs. AS1
- AS1 uses SMTP (Simple Mail Transfer Protocol) for transport vs HTTP/S
- AS2 superseded AS1, or Applicability Statement 1
- AS2 is a faster and more secure than AS1
- AS2 enables synchronous communications, but MDN receipts are only delivered asynchronously over AS1
- Instead of sending files as attachments to email messages, AS2 enables you to transport messages directly from one client to another using a web server.
AS2 vs. AS3
- AS3 uses FTP (File Transfer Protocol) for transport vs HTTP/S
- AS3 is not a replacement or upgrade for AS2.
- It was released in 2006 to provide another way to securely exchange messages using FTP.
- AS2 allows for synchronous communications, while MDN receipts are always delivered asynchronously over AS3
AS2 vs. AS4
- AS4 uses ebMS and web services for transport
- AS4, released in 2013 is a parallel implementation to AS2 and is in the early stages of adoption, providing several benefits vs. AS2
- Push & Pull - AS4 extends EDI to partners with limited web connectivity with pull functionality that lets recipients' machines be offline and come online anytime to receive messages
- Light Client - built on the OASIS ebMS 3.0 framework but without its more bulky features, AS4 supports both enterprise setups and a "light client" for partners with little IT infrastructure
- SOAP Web Services Integrations - many organizations use SOAP-based web services as an application programming interface (API) to send large, complex documents. As a SOAP-based web API layered on HTTP/S, AS4 helps teams that use APIs for internal integrations extend those integrations to partners.
Read about all the major types of EDI Protocols
AS2 EDI Software
ArcESB is the easiest-to-use Drummond-Certified solution for AS2. It supports all the major types of EDI standards and transactions, while providing built-in ports for robust data integration with 80+ popular tools and applications.