AS2 Protocol

Watch video ▶️

This guide provides a comprehensive description of the AS2 protocol, its operation, and its advantages to businesses, government or other organizations. It offers a complete reference for anyone implementing AS2 for B2B, EDI or other document exchange.

The high level layout is broken down as follows:

• What is AS2?
• Key aspects of AS2
• Business use of AS2
• AS2 Software

1 What is AS2?

AS2 or Applicability Statement 2, is a protocol used to securely exchange files through the internet, using the web protocol HTTP or HTTPS, as the transport mechanism. It is used extensively for the exchange of business documents such as EDI (either the American Standards Committee X12 or UN/EDIFACT) document types, XML, JSON, CSV, binary or flat files. It was defined by the RFC 4130 titled ‘MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)’, by Morberg and Drummond in 2005.

1.1 What is AS2 protocol for file transfers?

The AS2 protocol is primarily a secure file transfer protocol utilizing S/MIME capabilities for digital encryption, signature and non-repudiation. Unlike FTP, SFTP or FTPS, it operates over the web protocols HTTP and HTTPS, and is used extensively for the exchange of EDI files such as X12 or EDIFACT, and many other types of files such as XMl, JSON, CSV, Flat files, Text files, images or other binary or text files. The AS2 protocol secures the files with encryption, and uses digital signatures to guarantee the authenticity. Signed receipts issued by the receiver provides legally valid non-repudiation.

1.1.1 What is MIME and S/MIME?

Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. MIME message bodies can consist of several parts, along with header information about the contents of such parts. Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and signing of MIME data. S/MIME allows authentication, integrity, non-repudiation of origin, privacy and data security (using encryption) and forms the basis of AS2 message bodies. Refer MIME, S/MIME and AS2 for more details about MIME, S/MIME and the use in AS2.

1.2 How does AS2 differ from FTP or SFTP?

AS2 differs from traditional FTP or SFTP file transfer mechanisms, due to its use of payload hashing, digital signatures and encryption (See above). In addition, the digitally signed receipt called the Message Disposition Notification or MDN, issued by the recipient, serves the purpose of legally valid non-repudiation, which is not available in basic S/FTP or FTPS.

1.3 EDIINT Applicability Statements from the IETF

1.3.1 What is an Applicability Statement or AS?

An Applicability Statement is a set of recommendations on how to apply existing standards to facilitate secure business communications over the Internet. The AS protocols build on top of existing standards such as MIME, S/MIME & HTTP/S. The following diagram shows how AS protocol based communication software interfaces with business applications or EDI translation software, and then exchanges the messages with the counterpart AS software of a trading partner.

1.3.2 EDIINT AS2

AS2 is usually referred to as EDIINT AS2, which stands for Electric Data Interchange over the INTernet (EDIINT). EDIINT is a Working Group of the Internet Engineering Task Force (IETF), tasked with the responsibility to create secure protocols for business communications over the Internet. The EDIINT working group has created the AS1, AS2 and AS3 protocols for the exchange of EDI documents between businesses.

1.3.3 AS1 vs AS2

RFC 3335 of 2002 first defined AS1 as ‘MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet’. While AS1 was somewhat similar to AS2, it depended on SMTP and POP3 (or Email) as the transport, and PGP/MIME and S/MIME for security.

1.3.4 AS3 vs AS2

AS3 was defined in 2007 by RFC 4823 as ‘FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet’. It mainly differed with AS2 due to its use of FTP as the transport mechanism.

1.3.5 AS4 vs AS2

The ‘AS4 Profile’ of ebMS 3.0 became an OASIS Standard in 2013, and used Web Services for the exchange of documents. It utilized XML encryption and XML digital signatures from WS-Security, for security. AS4 is not an EDIINT or IETF standard.

1.3.6 AS2 vs AS1, AS3 and AS4

Due to its simplicity and adoption by many industries across the world, AS2 remains the most widely used and preferred mechanism today for the B2B exchange of EDI and other documents. While AS1 became obsolete with the adoption of AS2 by Walmart and other retail and healthcare organizations; AS3 and AS4 has not gained wide adoption, due to the popularity and use of AS2.

1.4 AS2 version 1.0, 1.1, 1.2 and optional extensions

The AS2 version 1.0 was defined by the RFC 4130, and is the most widely used version. As per the RFC, the version 1.1 is used by implementations that support compression, as defined by RFC 3274. Although a draft proposal for a version 1.2 proposed enhancements, it has not been accepted as a standard.

Optional extensions, commonly used with AS2 are as follows:

• Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT): RFC 6362

  Allow a single AS2 message to carry multiple files. This RFC uses the AS2 version ‘1.2’ and is supported by most AS2 software and used by many organizations. When used, the following additional HTTP headers are present within an AS2 request.

AS2-Version: 1.2
EDIINT-Features: multiple-attachments

• Filename Preservation for EDIINT - Draft

  Retains the original filename when transmitted over AS2. Although not an IETF standard at present, systems that depend on the filenames containing additional information such as a date or timestamp etc uses this extension. When used, a MIME body part encapsulating a file will include a ‘Content-Disposition’ header, indicating the filename.

Content-Type: application/edi-x12
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=myedifile.x12

MIAGCyqGSIb3DQEJEAEJo.....0nii7C5r8tfw==

• Certificate Exchange Messaging for EDIINT - Draft

  Allows the automatic exchange of certificates. This may provide useful when an organization exchanges files with hundreds of partners or more, and needs to keep all certificates updated in the face of expiry over time. However, this requires that all other partners also support this optional extension, which is rare. Almost all AS2 partners would manually share updated certificates over a separate medium such as email. Thus certificate rotations can be controlled manually, or on schedule, although the exchange itself is made outside of AS2.

1.5 What types of files can be exchanged through AS2?

AS2 was defined for the exchange of structured business documents, such Electronic Data Interchange (EDI) files. However, the AS2 specification is agnostic of the file content. Businesses of all types and sizes use AS2 to exchange files such as XML, JSON, CSV, Flat files, Text files and Images, in addition to EDI files.

2 Key aspects of AS2

How AS2 Works page details the internals of the AS2 protocol operation, providing a step by step explanation of the steps.

2.1 Encryption

The most common encryption algorithm used is Triple DES or 3DES. Algorithms such as AES-128, AES-192 & AES-256 are used in addition to a few more rarely used algorithms supported my most software. The sender always encrypts the payload with the public key / certificate of the receiver, so that only the receiver which has the corresponding private key can decrypt the message.

2.2 Digital Signature

Most common digital signature algorithm used is SHA1 with RSA. Algorithms such as SHA256 with RSA or SHA512 with RSA and MD5 with RSA are also used in addition to a few more rarely used algorithms supported by most software. The sender always digitally signs the payload with its private key. The receiver, which has the corresponding public key / certificate of the sender, can then verify the origin and authenticity of the message.

2.3 Hash function

A secure hash calculated over the payload generates the Message Integrity Check or MIC. The most commonly used algorithm for the generation of the MIC is SHA1. Algorithms such as SHA256 and MD5 are used as well, in addition to a few more rarely used algorithms. When a signed receipt has been requested by the sender, the receiver computes the MIC over the received payload, and composes a digitally signed Message Disposition Notice (MDN) encompassing the MIC value.

2.4 Certificates

AS2 performs encryption and signing using asymmetric key encryption, which depend on a mathematically related pair of interchangeable keys called a key pair. The owner of a keypair keeps one of these keys privately, and this is called the private key. The keypair owner then shares the other key called the public key, with its partners. The public key shared as an X509 digital certificate, includes auxiliary information of the owner such as its common name (CN), organizational unit (OU), organization (O) and country etc.

2.4.1 Self-signed certificates

Partners utilizing AS2 communications routinely exchange AS2 information such as AS2 ID, URL and certificates over a separate and trusted medium such as email. Many AS2 partners generate self-signed certificates and use these key pairs for encryption and digital signatures. These certificates exchanged securely through a channel trusted by both parties such as email, will not require a third party Certification Authority (CA) to sign them as valid. Most AS2 communications use self-signed certificates.

2.4.2 Certificate Exchange

Each party shares its public key with the other party before performing AS2 communications. The parties use Email for this certificate exchange most of the time. Each party sends the certificates to the other party, along with the AS2 identifier and URL. Each Sender thus has shared its public key / certificate with each receiver, and each receiver has shared its public key / certificate with each sender.

2.4.3 Separate certificates for Encryption and Signatures

Most AS2 partners use a single key-pair for both encryption and signatures, and to keep the configurations simple. However, the RFC does not prohibit the use of separate key-pairs for encryption and signatures, and some partners use them in practice. In such instances the Sender would encrypt an AS2 message with the certificate provided by the receiver for encryption. For verification of a digital signature, such as that for a received MDN, the sender would use a different certificate, provided by the receiver.

2.5 Message Disposition Notification (MDN)

Message Disposition Notification or MDN is a digitally signed receipt over the content of a file received by the recipient, which is sent back to the sender as an acknowledgement. This is one of the key advantages of the AS2 protocol which allows non-repudiation, so that the sender can confirm the uncompromised and intact receipt and acknowledgement of the file by the receiver. Although almost always used in practice, the use of an MDN is optional as per the specification, and left for the parties to decide.

2.5.1 Sending MDN

The MDN is usually sent back as the HTTP response to an incoming AS2 message, and is referred to as a Synchronous MDN. The HTTP status code 200 indicates a successful response, including an HTTP body, which contains the MDN.

An asynchronous MDN is an MDN sent back as a new HTTP message from the receiver back to the sender, to a URL specified for such purpose. The receiver acknowledges the original HTTP request carrying the AS2 request with an HTTP 202 status, which indicates a successful acceptance, but without a response body. Afterwards, the receiver creates a new HTTP request for the MDN and sends it back to the sender’s asynchronous MDN URL. The sender acknowledges this MDN with another HTTP 202 response.

2.5.2 Requesting an MDN

An MDN is requested by placing a ‘Disposition-notification-to’ header into an AS2 request. Its value can be an email for a synchronous MDN, or an URL for an asynchrnous MDN.

Requesting a synchronous MDN

Message-Id: <28791khkhl@mftgateway.com">
Disposition-Notification-To: acme@mftgateway.com

The presence of a ‘Receipt-delivery-option: return-url’ indicates that the MDN should be sent asynchronously to the specified URL. The MDN message carries a ‘Original-Message-Id’ header allowing message reconciliation against the ‘Message-ID’ of the original message for which the MDN is issued.

Requesting an asynchronous MDN

Message-Id: <28791khkhl@mftgateway.com">
Disposition-Notification-To: http://mftgateway.com/as2/async
Receipt-delivery-option: http://mftgateway.com/as2/async

2.5.3 MDN Options

The ‘Disposition-Notification-Options’ header specifies additional options regarding the MDN. The ‘signed-receipt-protocol’ option indicates a signed MDN is requested, and if that is a requirement or something optional. Additionally, the ‘signed-receipt-micalg’ parameter specifies the MIC algorithm to be used such as MD5, SHA1 or SHA256 etc, and if that is required or optional.

Disposition-Notification-Options: 
  signed-receipt-protocol=optional,pkcs7-signature; 
  signed-receipt-micalg=optional,sha1

2.5.4 Contents of a MDN

Listed below is a sample signed MDN. Note that the ‘application/pkcs7-signature’ part contains the signature at the outermost level, indicating its Content-Type as ‘S/MIME Cryptographic Signature’. The signed contents of the type ‘multipart/report’ is the actual MDN, which includes a human-readable ‘text/plain’ part, and a machine-readable ‘message/disposition-notification’ part. The machine-readable part is the legal MDN, allowing the sender to prove at a later time if required, that the original message it sent, over which the computed Message Integrity Check (MIC) holds true, has been confirmed as received by the recipient, by placing its digital signature over the message ID and MIC.

2.6 Flexibility of the AS2 protocol

The AS2 specification does not enforce the use of encryption or digital signatures, and leaves the options to the interacting trading partners to decide. An MDN can also be required, or left as optional, to be decided by the receiver. Similarly, the option to use synchronous or asynchronous MDNs, as well as the hash functions and message digest choices, are also left to the parties to decide.

Most AS2 interactions use both encryption and digital signatures by default, and request a synchronous, signed MDN receipt. Although not always used, the following permutations are possible as per RFC 4130 Section 2.4.2

• Sender sends un-encrypted data and does NOT request a receipt.
• Sender sends un-encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
• Sender sends un-encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
• Sender sends encrypted data and does NOT request a receipt.
• Sender sends encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
• Sender sends encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
• Sender sends signed data and does NOT request a signed or unsigned receipt.
• Sender sends signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
• Sender sends signed data and requests a signed receipt. Receiver sends back the signed receipt.
• Sender sends encrypted and signed data and does NOT request a signed or unsigned receipt.
• Sender sends encrypted and signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
• Sender sends encrypted and signed data and requests a signed receipt. Receiver sends back the signed receipt.

3 Business use of AS2

Importance of AS2 details the importance of AS2 and its relevancy and importance in the current times. Although many new technologies emerge each year, most business platforms rely on the standards based Electronic Data Interchange (EDI) formats using US X12 or UN EDIFACT, and exchange these through files over AS2.

3.1 Adoption of AS2 by the retail industry

The adoption of AS2 grew rapidly since the early 2000’s after major players in the retail industry, lead by Walmart, mandated its use by suppliers, instead of exchanging files over dial-up modems. This was followed by other large buyers such as Amazon, Target etc.

3.2 Adoption of AS2 by the Healthcare industry

The healthcare industry followed the retail industry, especially to meet the legal HIPPA requirements in the exchange of files, by using AS2. The US Food and Drug Administration (FDA) also uses the AS2 protocol to accept electronic regulatory submissions.

3.3 Adoption of AS2 over expensive VANs

The use of the web protocols HTTP/S meant that connections between partners could be established over the Internet. This allowed communications without dependence on specialized networks called ‘Value-Added Networks’ (VAN) which emerged in the ’70s and were more expensive. Value Added Networks provide hosted service offerings, and acts as an intermediary between business partners. Although VANs were widely used during the days of leased lines and private networks, AS2 has since been adopted by many organizations due to its lower operational costs and simplicity. VANs might provide capabilities where different partners use other more traditional protocols such as FTP, FTPS or SFTP in addition to AS2. In such scenarios, a file could be handed over to the VAN to be sent over to the destination partners using the preferred format of each partner.

3.4 Simplicity of operating over HTTP/S

Using HTTP or HTTPS as the underlying transport meant that AS2 could operate more easily through corporate firewalls and the Internet. IP based firewall restrictions and rules, or HTTP authentication could be implemented for additional security, while it was still possible to troubleshoot potential connectivity issues with ease. The AS2 software exposed to the Internet could be deployed on demilitarized zones (DMZs) for additional security.

4 AS2 communication

Exchanging files using the AS2 protocol with digital signatures, encryption and MDNs is called AS2 communication. This is provided by AS2 Software deployed on-premise, or cloud, or utilized as a service (SaaS).

4.1 AS2 Software

Software capable of communicating over the AS2 protocol, are called AS2 Servers, AS2 Stations or AS2 Services; i.e AS2 Software. Similar to having a mail server or website hosted within a corporate network, an AS2 server can also be deployed within an internal corporate network. Such AS2 servers must be exposed to the Internet 24x7 to be ready to accept any transmissions sent by remote partners at any time, quite similar to an email server.

AS2 servers can be deployed outside a corporate network, such as on the cloud. Another common option is to use AS2 as a Service in the common Software as a Service (SaaS) model. This requires no hardware or software to be purchased, installed or maintained, much like using a web email service. Files provided to the AS2 solution will be transmitted out to the destination partners over AS2, while files received over AS2 will be accepted and stored for later consumption, much like store-and-forward email.

AS2 software will present interfaces to set up one or more AS2 identities for the organization. Such an identity is usually called an AS2 Station. A partner usually has one Station which is used for both testing and production. This way, it is easier to switch to production use, as no changes are necessary, but just the identification that files received from that moment onwards are real production files. An organization may also choose to create two stations for Testing and Production use. Large organizations usually have two such stations.

4.1.1 AS2 Error handling

If a sending partner is unable to successfully read the HTTP response, the POST operation with identical data should repeat once again at a later time. This allows AS2 communications to automatically heal errors such as network timeouts, planned or unexpected downtime, as the originating systems will retry operations automatically (Section 5.5 of the RFC 4130).

4.1.2 Replay of messages / Duplicate detection

As business documents normally contain transaction IDs (e.g. X12 ISA/GS or ST headers), replays (such as resends of not-yet-acknowledged messages) are discarded as part of the normal process of duplicate detection. The RFC recommends the detection of duplicates by Message-Id or by business transaction identifiers. With EDI systems already performing duplicate detection, such validations requiring more complexity, are not used in practice at the AS2 layer.

4.1.3 Can someone see files exchanged over AS2?

By default, AS2 uses encryption, irrespective of the transport being HTTP or HTTPS. The file to be transmitted is encrypted with the public certificate of the recipient. This ensures that only the intended recipient, who has the private key of that keypair (used within the certificate) can decrypt the contents. See Public Key Cryptography for more details. Thus, even if the contents are to be intercepted by an intermediary or attacker, they will never be able to decrypt the contents, even if SSL/TLS security - if used, is compromised.

4.1.4 Can someone change the content of files exchanged over AS2?

By default, AS2 uses digital signatures, in addition to encryption. To compute the signature, a secure hash algorithm such as SHA-1 or SHA-256 is used, along with the private key of the sender. This signature is sent along with the AS2 message. By validating the signature after receipt, the receiver is able to verify that the file has not been changed during transmission and is the same content digitally signed by the sender.

4.1.3 Are AS2 communications one-way?

Once an AS2 connection has been set up between two partners, either partner can send or receive files from each other. However, each such transmission is one-way and does not default to a request-response pair. Higher level layers such as EDI may require each submission to be followed by a functional acknowledgement such as an X12 997. Such a functional acknowledgement is a separate AS2 file exchange on the reverse direction. When MDNs are used, one can consider the MDN as a natural response to a request. MDNs can be synchronous or asynchronous (See above).

4.1.4 Does AS2 compress files?

AS2 messages are usually uncompressed, and the files transmitted as-is. The sender can optionally compress files on send, and this could be helpful to compress large EDI or text based files efficiently. Compressed messages will be automatically detected by the recipient, which will transparently decompress them on receipt.

4.1.5 What is AS2 EDI?

The term ‘AS2 EDI’ is used when AS2 is utilized to exchange EDI files such as X12 or EDIFACT files.

4.1.6 Can an AS2 transmission send more than one file?

AS2 messages usually contain one file. However, there is an optional capability called multiple attachments, where many files can be transmitted at once, within a single message.

4.2 What is AS2 Integration?

AS2 integration means the electronic interconnection of businesses through the AS2 protocol. For example, integrating with Walmart over the AS2 protocol allows a supplier to receive electronic Purchase Orders as files in the X12 850 format. The Supplier can then transmit the Advance Ship Notifications as files using the X12 856 format, and finally send Invoices as X12 810 files to Walmart. This will allow businesses to electronically integrate backend systems, avoid manual data entry, and the postage of purchase orders or invoices as printed documents.

4.3 What is an AS2 URL?

AS2 software operates similar to a regular web server, to accept traffic over the Internet. This similar to a web page or API exposed over the Internet, the AS2 solution also exposes a specific URL for external partners to send messages. When asynchronous MDNs are used, a separate URL may exist to receive such async MDN responses.

4.3.1 Are HTTPS AS2 URLs better than HTTP URLs?

AS2 typically performs digital encryption of the contents before transmission. Thus using HTTPS with SSL or TLS transport level security, adds additional security to the communications. The use of HTTP based URLs and HTTP as the transport does not expose any security threat, if the payload has already been encrypted and digitally signed by the AS2 protocol.

4.3.2 What is the AS2 port?

AS2 software usually uses port 4080 to receive HTTP messages, and port 5443 to receive HTTPS (SSL) messages. Since AS2 operates over the web protocols, its default port 80 when using plain HTTP, and port 443 when using HTTPS with SSL or TLS security, are also commonly used. Certain trading partners might require its partners to use a specific port. For example, the US Food and Drug Administration (FDA) requires its partners to use the HTTP over port 4080.

4.4 What is an AS2 Identifier or ID?

An AS2 identifier is similar to an email address and helps partners uniquely identify each other. As per the RFC4130 these can contain 1 to 128 characters from the ASCII decimal values 32, 35 to 91 and 93 to 126. In simple terms, this means the set of printable ASCII characters except space (%d32), double quote (%d34) or backslash (%d92). Usually each partner selects its company name, in upper case letters.

4.5 What is Drummond Certification

Rik Drummond was one of the co-authors of the AS2 specification RFC 4130 in 2005, and was a co-founder of the Drummond Group (Drummond), founded in 1999. Drummond helps companies navigate complex regulatory compliance, security, and risk-management environments. Drummond conducts interoperability certification for AS2, AS3 and AS4, among others. Interoperability certification from Drummond guarantees interoperability with other such Drummond certified AS2 products.

The AS2 specification defined by IETF RFC 4130 is an open standard, similar to other popular technologies defined by open standards, such as HTTP RFC 2616 or S/MIME RFC 8551 etc. An AS2 implementation can completely implement and conform to the specification, and achieve full interoperability with other AS2 products, without necessarily participating in the paid Drummond certification process.