Table of Contents
The eDelivery AS4 Profile is a modular profile of the ebMS3 and AS4 OASIS specifications. Its core is a mandatory Common Profile that selects, extends and profiles the AS4 ebHandler Conformance Profile and AS4 Additional Features and provides a common Usage Profile. This Common Profile can be implemented using open source or closed source AS4 software implementations. It is aligned with, and corresponds to a subset of, the AS4 profile for TSOs (Transmission System Operators) developed by ENTSOG (the European Network of Transmission System Operators for Gas).
In addition to the Common Profile, this specification provides a number of optional Profile Enhancement modules that specify functionality enhancements covering AS4 message exchange in four corner topologies, the use of AS4 in conjunction with the UN/CEFACT Standard Business Document Header (SBDH) specification, and Dynamic Receiver and Dynamic Sender behavior.
This specification is based on the following OASIS specifications:
The following table summarizes the features provided by the ebMS3 and AS4 specifications. The eDelivery profile is a profiled extended subset of the features of the AS4 specification.
Table 1. ebMS3/AS4 Functional Overview. (*) in ebMS3, not in AS4 (**) AS4 extension to ebMS3
The AS4 technical specification [AS4] defines a secure and reliable messaging protocol. It can be used for message exchange in Business-to-Business (B2B), Administration-to-Administration (A2A), Administration-to-Business (A2B) and Business-to-Administration (B2A) contexts. AS4 messages can carry any number of payloads. Payloads may be structured or unstructured documents or data.
Message packaging provided by AS4 as an add-on feature relies on ebMS 3.0 [EBMS3] support for the SOAP 1.2 specification [SOAP12]. AS4 combines the traditional functional support of payload compression in line with ebMS 3.0 message packaging norms. Compression in AS4, if used, must be applied prior to the application of any message-level security such as digital signing or encryption. AS4 does not define a maximum message size, though implementations will have practical limits based on available memory, disk or database storage etc.
AS4 offers a secure exchange protocol for use over the Internet that leverages the MIME envelope structure to transport arbitrary payloads. Support for Message Security is provided by AS4 via ebMS 3.0 and the WS-Security 1.1 and 1.1.1. specifications. This includes combinations of XML Digital Signature and XML Encryption X.509 security tokens for signing and encrypting as primary means for authenticating messages, ensuring privacy, and guaranteeing safe data transmission. Additionally, AS4 supports the use username/password tokens as access control to message pull channels.
The ebMS 3.0 and AS4 specifications provide support for Non-Repudiation of Receipt (NRR) by using a Signed Receipt Signal Message. The receipt is returned using a special signal message. Signal messages may also contain error handling information if there was some problem with the exchange.
AS4 makes use of the message receipt as a signal to the original message sender that the business payload (or payloads) has (have) been received. AS4 supports duplicate message detection and message retry/resending scenarios for when receipts for messages are not received by the sender.
Other technical highlights are:
Note that this version of this eDelivery AS4 specification does not use all features of ebMS3 and AS4. Specifically, it does not use the Pull pattern. Future versions of this profile may require additional support for Pull or other additional features not currently included. For a complete feature list, see section 3.2.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
As in the ebMS3 Core Specification [EBMS3], this specification uses the term P-Mode to refer to an ebMS3 Processing Mode and PMode in P-Mode parameter labels. Furthermore, this specification uses the notation PMode to generalize over parameters that apply to the user message in the single leg in a One Way exchange, i.e. PMode, or that are specified separately for the user messages in the two legs in a Two Way exchange, i.e. PMode and PMode. In section 4.4.2, there is a need for a parameter to configure the X.509 certificate used to sign the receipt or error signal message in a leg. This is done using the PMode[s] sequence in the PMode[s].Security.X509.Signature.Certificate parameter, following the pattern introduced in section D.2.1 of the ebMS3 Core Specification [EBMS3].
The eDelivery AS4 Common Profile profiles the OASIS ebMS3 and AS4 specifications. The eDelivery AS4 Common Profile selects the AS4 ebHandler Conformance Profile, a specific conformance profile defined in the AS4 specification [AS4], and makes a selection of AS4 Advanced Features. The selected Conformance Profile and selected Advanced Features are profiled further for increased consistency, ease of configuration and up to date security. Finally, this Common Profile provides a common AS4 Usage Profile. An AS4 Usage Profile defines how to use a conformant implementation for general exchange of any arbitrary payload combinations. This eDelivery AS4 Common Profile explains that some features available in the AS4 ebHandler Profile are not used (such as Pull exchange pattern bindings and WS-Security Username token authentication), whereas other optional features (TLS, XML Signature and XML Encryption) are mandatory and used with specific algorithms. The Common Profile extends AS4 by using more up to date versions of some underlying specifications and mandating support for the Two-Way MEP.
This eDelivery Common Profile is based on the ENTSOG AS4 profile for TSOs (Transmission System Operators). ENTSOG, the European Network of Transmission System Operators for Gas, developed ENTSOG AS4 as a secure interoperability profile for AS4 [ENTSOGAS4]. This profile incorporates state-of-the-art security guidelines and has been reviewed by experts from the European Union Agency for Network and Information Security (ENISA). This eDelivery AS4 Common Profile is the same as the ENTSOG profile, for general AS4 messaging aspects.
AS4 and Conformance Profiles
The eDelivery AS4 profile is based on the AS4 Profile of the ebMS 3.0 Version 1.0 OASIS specification [AS4]. AS4 is based on other specifications, in particular on OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features OASIS specification [EBMS3], which in turn is based on various Web Services specifications. The OASIS Technical Committee responsible for maintaining the AS4, ebMS 3.0 Core and other related specifications is tracking and resolving issues in the specifications [EBERRATA]. These resolutions will eventually be published as a consolidated Specification Errata but should already be taken into account by implementers, to avoid functional or interoperability issues.
The AS4 specification defines multiple conformance profiles, which define specific functional subsets of the version 3.0 ebXML Messaging, Core Specification. A conformance profile corresponds to a class of conformant applications. This Common Profile of AS4 is based on an extended subset of the AS4 ebHandler Conformance Profile, a selection of AS4 Advanced Features and a Usage Profile. It supports point-to-point communication from Senders to Receivers using eDelivery Access Points using the ebMS3 “Push” transport channel binding. The optional Four Corner Topology feature extends this to interconnection of messaging infrastructures.
By using “Push”, messages that are submitted by a Producer to a Sending ebMS3 Message Service Handler (MSH) are transmitted to the Receiving ebMS3 MSH immediately, without the (unpredictable) delay of a “Pull” transport channel binding. Assuming the latency of the transmission of the request message from the Receiving MSH to the Consumer, the business processing of the request message content by the Consumer and the reverse flow of the response message from the Consumer back to the Producer, using their Message Service Handlers in reverse sequence, can be minimized, this profile can also support time-critical business processes that need “interactive” responses.
eDelivery AS4 ebHandler Feature Set
The feature set of the eDelivery AS4 Common Profile is, with some exceptions, a subset of the feature set of the AS4 ebHandler Conformance Profile specified in section 2.1.1 of the AS4 specification [AS4]. This section selects specific options in situations where the AS4 ebHandler provides more than one option to choose from. This section can therefore be used as a checklist of features to be provided in AS4 implementations. The structure of this section mirrors the structure of the ebMS3 Core Specification [EBMS3]. The ebMS 3.0 protocol can support synchronous as well as asynchronous communication and provides full convergence with Web Services. It reuses the SOAP 1.2, WS-Security 1.1, and SOAP-with-attachments specifications. It conforms to the WS-I Basic Profile (BP) and Basic Security Profile (BSP) and provides additional features of particular relevance to small and medium-size enterprise, in particular message pulling. AS4 drops the requirement for synchronous exchange of user messages but the AS4 ebHandler Conformance Profile allows synchronous and asynchronous signal messages.
Compared to the AS4 ebHandler Conformance Profile, this eDelivery Common Profile profile updates, and adds, some functionality:
It also relaxes some requirements:
Message Exchange Patterns
The following paragraphs summarize some key concepts and terminology defined in the ebMS 3.0 core specification [EBMS3]:
Business applications or middleware, acting as Producer, Submit message content and metadata to the Sending MSH, which packages this content and Sends it to the Receiving MSH of the business partner, which Receives it and in turn Delivers the message to another business application or middleware that Consumes the message. Subject to configuration, Sending and Receiving MSH may Notify Producer or Consumer of particular events. Note that there is a difference between Sender and Initiator. For Push exchanges, the Sending MSH initiates the transmission of the message. For Pull exchanges (not supported in the eDelivery Common Profile), the transmission is initiated by the Receiving MSH. Also note that a business application can include MSH functionality, leaving the MSH as an abstract concept.
The concepts of Producer, Sender, Receiver and Consumer are separate from, and are not to be confused with, the corners in the Four Corner Topology concept (see section 4.1). While separate components, the Message Producer and Sending MSH entities MAY be enterprise-internal components only and MAY not be associated with different communication, business or legal identities. Sending and Receiving MSH are messaging endpoints, not intermediaries.
Different Message Producers MAY share a single Sending MSH and a single Receiving MSH MAY serve different Message Consumers and provide message routing functionality, using message metadata or payload content as routing delivery criteria. For example, different values of the AS4 eb:Service header could be used to select a specific Consumer. Specification of this functionality is out of scope for this specification.
A single MSH is said to be multi-tenant if it MAY be configured to send messages on behalf of multiple sender entities or to receive messages on behalf of multiple receiver entities using distinct identities, each possibly associated with distinct processing mode configurations including different party identifiers, certificates and endpoint URLs. Implementation and configuration of this feature is implementation-dependent.
The AS4 ebHandler Conformance Profile is the AS4 conformance profile that provides support for Sending and Receiving roles using Push channel bindings. Support is required for the following Message Exchange Patterns:
In the context of ebMS message exchanges, pushing means that the sender initiates the message exchange. For HTTP, this implies that the Sending MSH is acting as an HTTP client, and the Receiving MSH as an HTTP server. Pulling means that the receiver initiates the message exchange. For HTTP, in that situation the Receiver MSH is an HTTP client and the Sending MSH is an HTTP server.
The One-Way/Push MEP specifies a situation when a Sending MSH which has agreed to use the One-Way/Push MEP sends a message to a Receiving MSH which has agreed to use One-Way/Push MEP as well. After the successful reception of the message, the receiving MSH returns a non-user message (i.e. a signal message) to the sending MSH to confirm the reception. Different user messages do not have any reference to each other, except possibly if they are part of the same conversation.
Figure 2. One-Way/Push MEP [EBMS3].
While the AS4 ebHandler does not require support for the Two-Way MEP, support for this MEP is REQUIRED in this eDelivery Common Profile. It can be used for business processes involving correlated pairs of request and response messages. A message handler that supports Two Way MEPs allows the Producer submitting a response user message unit to set the optional eb:RefToMessageId element in the eb:MessageInfo section to identify the corresponding request user message unit.
For PMode.MEP, support is therefore required for the following values:
For PMode.MEPbinding, support is required for:
Note that these URI values are identifiers only, which are defined in section 2.2.8 of the ebMS3 specification. They do not resolve to content on the OASIS site.
Time-critical processes require the Push channel binding, because it allows the Sender to control the timing of transmission of the message. Interactive, request-response communication between parties A and B can be provided as a combination of two Push messages, one from the Sending MSH, on behalf of A, to the Receiving MSH, which in turn acts as Receiver for B, followed by a separate (asynchronous) response message from B using its MSH to A's MSH.
The Two-Way/Sync MEP specifies a situation in which the Sending MSH and the Receiving MSH use a single HTTPS connection to exchange both a request message and the corresponding response message. The Sending MSH is the Initiating MSH, which acts as an HTTPS client and sends the request message. The Receiving MSH is the Responding MSH, acting as an HTTPS server. It receives the request message and returns a response message on the HTTPS backchannel. The Sync transport channel binding is not part of the OASIS AS4 profile and not currently part of this eDelivery AS4 Common Profile.
The Two-Way/Push-and-Push MEP is very similar to a sequence of two One-Way/Push exchanges, in which the Sender and Receiver roles are reversed. The Responding MSH, which received the request User Message in the first exchange, becomes the Sending MSH in a second, separate exchange in which the business response User Message is transmitted. This second exchange is separately initiated and, unlike the Sync channel binding, does not depend on any connection timeout intervals of the underlying HTTP transport. The Two-Way/Push-and-Push MEP MUST be supported in conformant eDelivery AS4 implementations.
In any Two Way Message Exchange, the response User Message MUST have a eb:RefToMessageId element with the value set to the value of the eb:MessageId in the corresponding request message.
AS4 Message Structure and UserMessage
The AS4 Message Structure provides a standard message header that addresses common data exchange requirements and offers a flexible packaging mechanism based on SOAP and MIME enveloping. Dashed line style is used for optional message components.
The SOAP envelope SHOULD be encoded as UTF-8 (see [EBMS3], section 188.8.131.52). If the SOAP envelope is correctly encoded in UTF-8 and the character set header is set to UTF-8, receivers MUST support the presence of the Unicode Byte Order Mark (BOM; see [BP20], section 3.1.2).
AS4 defines the ebMS3 eb:Messaging SOAP header, which in user messages is an envelope for eb:UserMessage XML structures, which provide business metadata to exchange payloads. In AS4, ebMS3 messages other than receipts or errors carry a single eb:UserMessage.
A conformant implementation, acting as Sending MSH, MUST allow the Producer, when submitting a user message, to:
A conformant implementation, acting as Receiving MSH, MUST provide the values of eb:MessageId, eb:ConversationId and, if available, eb:RefToMessageId, as metadata with any user message it delivers to the Consumer.
To be able to relate a business response message to a previous business request, the Producer MUST know the eb:MessageId of this request message. The implementation of this requirement is left to implementations, but MAY be one of the following:
The ebMS3 and AS4 specifications do not constrain the value of eb:MessageId beyond requiring conformance to the Internet Message Format [RFC2822], which requires the value to be unique and use the msg-id format defined in section 3.6.4 of [RFC2822]. It is RECOMMENDED that the value include a universally unique identifier in the id-left part of the msg-id identifier.
Conformant implementations MUST be able to configure the presence and value of the eb:AgreementRef header content and its type attribute by configuring the applicable PMode.Agreement parameter.
A conformant implementation MUST allow the Producer, when submitting messages, to set a value for eb:AgreementRef, and to use this to select a particular P-Mode.
A conformant implementation, acting as Receiver, MUST take the presence, values and attribute values of all ebMS3 headers set using P-Mode parameters, including the eb:From/eb:PartyID, eb:From/Role, eb:To/PartyID, eb:To/Role, eb:Service, eb:Action and eb:AgreementRef header into account when selecting the applicable P-Mode. It MUST be able to send and receive messages in which the optional pmode attribute of eb:AgreementRef is not set.
As in the AS4 ebHandler profile, support for eb:MessageProperties is REQUIRED in this profile. It MUST be possible to set the type attribute for message properties (see https://issues.oasis-open.org/browse/EBXMLMSG-2). No use of specific Message Properties is specified in this Common Profile, but the feature is used in the optional Four Corner Topology enhancement.
Section 5.1.1 of the ebMS3 Core Specification [EBMS3] requires implementations to process both non-multipart (simple SOAP) messages and multipart (SOAP-with-attachments) messages, and this is a requirement for the AS4 ebHandler Conformance Profile. AS4 messages based on this eDelivery AS4 profile MUST NOT include any payload content in the SOAP body. Due to the mandatory use of the AS4 compression feature in this profile (see section 184.108.40.206), XML payloads MAY be converted to binary data, which is carried in separate MIME parts and not in the SOAP Body. Conformant eDelivery AS4 messages therefore always have an empty SOAP Body.
The ebMS3 mechanism of supporting "external" payloads via hyperlink references (as mentioned in section 220.127.116.11 of the ebMS3 Core Specification [EBMS3]) MUST NOT be used.
If AS4 is used to exchange multiple payload parts in a single message, and there are cross-references between payloads encoded using Content-ID resource locator syntax [RFC2392], the submitting Producer MUST be able to set Content-ID values for MIME payload parts and the Receiving MSH MUST make payload part Content-ID information available to the Consumer. Note that as an alternative to the use of the MIME Content-ID AS4 offers the option to assign part properties to each payload included in the message which can also be used for cross-references between payloads. To obviate the need for cross-references between payloads the Producer can also package them into one container part before submitting to the MSH.
A Producer that submits a message with multiple payloads to an MSH MUST be able to control the order of the corresponding eb:PartInfo elements in the ebMS3 eb:PayloadInfo element. An MSH that delivers a message with multiple payloads to a Consumer MUST provide information on the order of the corresponding eb:PartInfo elements in the ebMS3 eb:PayloadInfo element.
Support for eb:PartProperties is REQUIRED. A Producer MUST be able to specify properties and values for a submitted payload part and the Consumer MUST be able to read specified properties and values for delivered payload parts.
Section 5.2.2 of [EBMS3] defines a server test feature that allows a party to "Ping" a communication partner. The feature is based on messages with the values of:
This feature allows communication partners to perform a basic test of the communication configuration (including security at network, transport and message layer, and reliability) in any environment, including the production environment. A conformant implementation MUST allow configuration of processing modes for exchanges involving these values for service and action. It MUST be possible to configure an MSH such that messages with these values are not delivered to any Consumer business application.
For the error handling feature this profile specifies that errors MUST be reported and transmitted synchronously to the Sender and SHOULD be reported to the Consumer and the Producer. Note that the two error notification parameters do not affect interoperability between Sender and Receiver MSH.
The AS4 option to transmit errors using asynchronous messages MUST NOT be used.
As the interface between Producer and MSH and between MSH and Consumer is not defined in AS4, the formats and protocols used to report errors to Producer or Consumer are implementation-dependent.
Configuration of additional error handling specific to Reliable Messaging and Reception Awareness is described in section 3.3.2.
AS4 message exchanges can be secured at multiple communication layers: the network layer, the transport layer, the message layer and the payload layer. The first and last of these are not normally handled by B2B communication software and therefore out of scope for this sub-section. Transport layer security is addressed, even though its functionality may be offloaded to another infrastructure component.
This section provides parameter settings based on multiple published sets of best practices. It is noted that after publication of this specification, previously unknown vulnerabilities may be discovered in the security algorithms, formats and exchange protocols specified in this section. Such discoveries SHOULD lead to revisions to this specification.
Transport Layer Security
When using AS4, Transport Layer Security (TLS) is an option to provide message confidentiality and authentication. Server authentication, using a server certificate, allows the client to make sure the HTTPS connection is set up with the right server. When a message is pushed, the Sending MSH authenticates the HTTPS server of the Receiving MSH.
Guidance on the use of Transport Layer Security is published in the ENISA Algorithms, Key Sizes and Parameters Report 2013 [ENISAAKSP] and in a Mindeststandard of the Bundesamt für Sicherheit in der Informationstechnik [BSITLS]. If TLS is handled by the AS4 message handler (and not off-loaded to some infrastructure component), then:
If TLS is not handled by the AS4 message handler, but by another component, then these requirements MUST be addressed by that component.
Transport Layer client authentication authenticates the Sender (when used with the Push MEP binding) or Receiver (when used with Pull). Since this profile uses WS-Security for message authentication, the use of client authentication at the Transport Layer can be considered redundant. Whether or not client authentication is to be used depends on the deployment environment. To support deployments that do require client authentication, implementations MUST allow Transport Layer client authentication to be configured for an AS4 HTTPS endpoint. Mutual Authentication or two way TLS Authentication is a combination of client and server authentication.
Message Layer Security
To provide message layer protection for AS4 messages, this profile REQUIRES the use of the following Web Services Security version 1.1.1 OASIS specifications, profiled in ebMS3.0 [EBMS3] and AS4 [AS4]:
The X.509 Certificate Token Profile supports the signing and encryption of AS4 messages. This profile REQUIRES the use of X.509 tokens for message signing and encryption, for all AS4 exchanges. The AS4 option of using Username Tokens, which is supported in the AS4 ebHandler Conformance Profile, MUST NOT be used. The AS4 message MUST be signed prior to being encrypted (see section 7.6 of [EBMS3CORE]).
AS4 message signing is based on the W3C XML Signature recommendation used by WS-Security. AS4 can be configured to use specific digest and signature algorithms based on identifiers defined in this recommendation. At the time of publication of the AS4 specification [AS4], the current version of W3C XML Signature was the June 2008, XML Signature, Second Edition specification [XMLDSIG]. The current version is the April 2013, Version 1.1 specification [XMLDSIG1], which defines important new algorithm identifiers, including identifiers for SHA2, and deprecates SHA1, in line with guidance from ENISA [ENISAAKSP].
This eDelivery AS4 profile uses the following AS4 parameters and values:
This eDelivery AS4 Common Profile anticipates an update to the OASIS AS4 specification to reference this newer version of the XML Signature specification.
The use of XML Signature in AS4 provides Non Repudiation of Origin (NRO) at Message Exchange level.
For encryption, WS-Security leverages the W3C XML Encryption recommendation used by WS-Security. The following AS4 processing mode parameters configure this feature:
As specified in section 5.1.6 of [AS4] and in https://issues.oasis-open.org/browse/EBXMLMSG-111, when XML Encryption is used, all and only payload MIME parts MUST be encrypted. The eb:Messaging header and any of its sub-elements MUST NOT be encrypted.
AS4 also references an older version of XML Encryption than the current one, [XMLENC] instead of [XMLENC1]. The AES 128 algorithm [AES] was already referenced in that earlier version. AES is fully consistent with current recommendations for “near term” future system use [ENISAAKSP]. However, the newer W3C XML Encryption specification recommends AES GCM strongly over any CBC block encryption algorithms.
In WS-Security, there are three mechanisms to reference a security token (see section 3.2 in [WSSX509]). The ebMS3 and AS4 specifications do not constrain this, neither do they provide a P-Mode parameter to select a specific option. For interoperability, implementations SHOULD therefore implement all three options. It is RECOMMENDED that implementations allow configuration of security token reference type, so that a compatible type can be selected for a communication partner. Note that as BinarySecurityToken is the most widely implemented option for security token references in AS4 implementations, implementations SHOULD implement this option.
Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys, such as symmetric keys used for encryption of message content. No parameter is defined to support configuration of key transport in [EBMS3]. Implementations MUST use the following algorithms on outbound messages and MUST accept them on inbound messages.:
For backwards compatibility with implementations of versions of eDelivery AS4 prior to version 1.13, implementations MAY also accept, on incoming messages, the use of other key transport algorithm options specified in section 5.5 of [XMLENC1].
AS4 implementations conformant with the eDelivery AS4 Common Profile SHOULD provide an Application Programming Interface (API) to manage (i.e. create, read, update and delete) AS4 configuration data, including Processing Mode parameter sets and X.509 certificates used for AS4 message exchanges. This is an abstract requirement only. Conformance to any specific API or data format is NOT REQUIRED.
Conformant implementations MUST support IPv4 and IPv6 networking.
Use of AS4 Additional Features
The OASIS AS4 specification defines a number of Additional Features. The eDelivery AS4 Common Profile REQUIRES support for the AS4 Compression and Reception Awareness and Duplication Detection features. None of the other AS4 Additional Features are used in the eDelivery AS4 Common Profile.
The OASIS AS4 specification defines Payload Compression as one of its additional features. Payload compression is a useful feature for many content types, including XML content, as it can speed up:
To compress the payload(s) of a message payload, the GZIP [RFC1952] compression algorithm MUST be used. GZIP is the only compression type currently supported in OASIS AS4.
The PartInfo element in the message header that relates to a compressed payload part MUST have an eb:Property element with its name attribute set to the value CompressionType. The content type of a compressed payload part MUST be application/gzip.
Presence of this part property is an indicator to the Receiving MSH that the Sending MSH has compressed a payload part. The receiving AS4 MSH MUST decompress any payload part(s) compressed by the Sending MSH before delivering the message.
When compression, signature and/or encryption are required, AS4 specifies that any attached payload(s) MUST be compressed prior to being signed and encrypted.
Use of compression is configured using the P-Mode parameter PMode.PayloadService.CompressionType. This parameter is defined as follows in [AS4]:
The parameter is REQUIRED with the value application/gzip in this eDelivery AS4 Common Profile.
In case an error occurs during decompression, the following error MUST be used: Code = EBMS:0303, Short Description = DecompressionFailure, Severity = Failure, Category = Communication.
The AS4 compression feature specifies the use of compression at the message layer, the structure and format of an AS4 message that uses AS4 compression, and the behavior of the Sending and Receiving MSH. Setting the AS4 compression P-Mode parameter enables the compression feature in the sending MSH, but use of compression is NOT REQUIRED for messages configured using the P-Mode as noted in https://issues.oasis-open.org/browse/EBXMLMSG-79. Whether or not compression is applied, for messages for which AS4 compression is enabled in its P-Mode, is therefore left to the implementation of the sending MSH.
A receiving MSH MUST NOT reject messages with payloads that are not compressed even though AS4 compression is specified in the P-Mode. However, the receiving MSH is REQUIRED to decompress any compressed payloads for messages for which the P-Mode specifies the use of AS4 compression, and for which the CompressionType part property is set to application/gzip.
As the CompressionType property is used by the AS4 Compression feature, which controls its presence or absence using a Processing Mode parameter, the property MUST NOT be set by the Producer and it MUST NOT be passed to the Consumer.
Reliable Messaging and Non-Repudiation of Receipt
For Reliable Messaging this profile specifies that AS4 non-repudiation receipts MUST be sent synchronously for each message type.
The AS4 option to transmit receipts using asynchronous messages MUST NOT be used.
An AS4 receipt indicates that the message has been "successfully processed by the Receiving MSH (i.e. not just “received”)" [AS4].
In this eDelivery AS4 Common Profile the use of the AS4 Reception Awareness feature is REQUIRED. This feature provides a built-in Retry mechanism that can help overcome temporary network or other issues and detection of message duplicates.
The PMode.ReceptionAwareness.Retry.Parameters and related PMode.ReceptionAwareness.DuplicateDetection.Parameters are sets of parameters configuring retries and duplicate detection. These parameters are not fully specified in [AS4] and are implementation-dependent. Implementations MUST support configuration of parameters for retries and duplicate detection.
In the ebMS3 Core Specification [EBMS3], the EBMS:0202 error, DeliveryFailure is defined in the context of the ebMS3 Reliable Messaging module, which is distinct from the AS4 Reception Awareness feature. It states that the DeliveryFailure error can be generated either on the Sender or on the Receiver side.
Note that, if the Receiving MSH does not return a DeliveryFailure error, or if, for some reason, transmission of this error to the Sending MSH fails, the Sending MSH MUST still generate and report the Missing Receipt error.
In the ebMS3 Core Specification [EBMS3], reporting of Delivery Failures to the Producer is configured using the parameter PMode.Errorhandling.DeliveryFailuresNotifyProducer. AS4 implementations may not support this parameter as it is linked to the ebMS3 Reliable Messaging module (see also https://issues.oasis-open.org/browse/EBXMLMSG-59), which is optional in AS4 and not used in this eDelivery profile. When using AS4 implementations that use this parameter for configuration of reporting by the Sending MSH of delivery failures to the Producer, this parameter MUST be set to true.
The WS-ReliableMessaging and WS-Reliability protocols, which are optional features in ebMS 3.0, MUST NOT be used in eDelivery AS4. Therefore, the PMode.Reliability parameters MUST NOT be used.
Common Usage Profile
This section specifies how implementations that conform to the eDelivery AS4 ebHandler MUST be configured and deployed. This is similar to the concept of Usage Agreements in section 5 of [AS4] as it does not constrain how AS4 implementations are implemented, but rather how they are configured and used. The audience for this section are operators/administrators of AS4 implementations and B2B integration project teams. The structure of this chapter also partly mirrors the structure of [EBMS3], and furthermore covers some aspects outside core B2B messaging functionality.
This profile REQUIRES an MSH to not include more than one eb:PartyId element in the eb:UserMessage/eb:PartyInfo/eb:From and eb:UserMessage/eb:PartyInfo/eb:To elements.
For party types registered in ISO 6523:
The use of ebCore Party ID MUST follow the profiling specified in the eDelivery ebCore Party Id specification [eDelivery-EBCORE].
AS4 provides multiple mechanisms to correlate messages within a particular flow.
The ebMS3 and AS4 specifications do not constrain the use of the elements eb:RefToMessageId and eb:ConversationId, but the following profiling applies:
Deployments of the eDelivery AS4 Common Profile MUST deploy, for each combination of values for the three parameters PMode.Initiator.Party, PMode.Responder.Party, PMode.Agreement defined in some deployed P-Mode, a P-Mode that has these values for these three parameters and uses the test service and action (see discussion above in the ebHandler Feature Set overview). For these three parameters, for each configured leg, for parameters other than PMode.BusinessInfo.Service and PMode.BusinessInfo.Action, this test service configuration MUST have the same parameters as the non-test service. This includes the values including the PMode.Security.X509 parameters.This allows communication partners to perform a basic test of the communication configuration (including security configuration at network, transport and message layer, and reliability) in any environment, including the production environment.
Deployments of the eDelivery AS4 Common Profile MUST be configured such that messages for the test service are not delivered to any business application.
Service, Action and Role
The ebMS3 specification [EBMS3] defines the eb:Service element as: “This REQUIRED element occurs once. It is a string identifying the service that acts on the message and it is specified by the designer of the service.” The header is of XML schema type non-empty-string and its value configured using the PMode.BusinessInfo.Service parameter, meaning communication partners are expected to define specific values for specific process modes, i.e. for various types of messages. The eb:Service element can have a type attribute to categorize services. It is not profiled in the eDelivery Common Usage Profile.
In [EBMS3], eb:Action is defined as: “This REQUIRED element occurs once. It is a string identifying the action the User message is intended to invoke on a particular service and it is specified by the designer of the service.” For each message exchange, [EBMS3] requires setting the values PMode.Initiator.Role and PMode.Responder.Role, which are used to set eb:From/eb:Role and eb:To/eb:Role values.
Users of the eDelivery AS4 Profile MUST agree on values for Services and, for each Service, the associated Actions. For each Service and Action, the From Role and To Role MUST be defined. This profile only provides high-level constraints on naming conventions on Service and Action.
This profile is intended to support exchange of AS4 messages using either the public Internet or private networks. Each party is individually responsible to implement security measures to protect access to its IT infrastructure.
Parties SHOULD use firewalls to restrict incoming and/or outgoing message flows to specific IP addresses, or address ranges. Parties therefore:
The Transport Layer Security settings defined in the eDelivery AS4 ebHandler Feature Set section MAY be implemented in the AS4 communication server (as specified above in the section covering the ebHandler Feature Set) but TLS MAY also be offloaded to a separate infrastructure component (such as a firewall, proxy server or router). In that case, the recommendations on TLS version and cipher suites [OSSLTLS] specified section in 3.2.6 MUST be addressed by that component.
The TLS cipher suites recommended in section 3.2.6. are supported in recent versions of TLS toolkits and therefore are available for use. Support for these suites is RECOMMENDED. Whether or not less secure cipher suites (which are only recommended for legacy applications) are allowed is a local policy decision.
This profile does NOT REQUIRE the use of client authentication. Client authentication MAY be a requirement in the networking policy of individual parties that the AS4 deployment needs to meet.
The following parameters control configuration of security at the message layer:
The eDelivery AS4 profile provides Non Repudiation of Origin and Receipt at the level of Message Exchange. Note that the use of non-repudiation information to resolve any disputes requires the communication partners to store data such as the exchanged AS4 messages, AS4 receipts corresponding to these messages, and possibly other verification data such as OCSP responses, for the period during which any such disputes may arise. The minimum retention period to be applied SHOULD be specified in a formal policy and be consistent with legal-regulatory requirements, business needs, and available storage/processing capacities. The AS4 message service handlers MUST be configured accordingly.
Message Payload and Flow Profile
In any exchange involving an AS4 eb:UserMessage that has a structured document payload and any number of associated payloads, the eb:UserMessage MUST reference the structured document payload part using the first eb:PartInfo element in the eb:PayloadInfo header. Subsequent eb:PartInfo elements MAY be used to reference additional structured or unstructured payload parts. The payload part referenced using the first eb:PartInfo element is the leading payload part for business processing. Any payload parts other than the leading document payload part MUST NOT to be processed in isolation but only as adjuncts to the business document. Structured document, attachments and metadata MUST be submitted and delivered as a logical unit.
The format and schema of structured document payloads SHOULD be agreed among sender and receiver parties and SHOULD be XML or JSON, but other structured data types MAY be supported in specific business processes or contexts.
Note that in ebMS3, when payloads are carried in MIME parts, eb:PartInfo elements reference the corresponding MIME parts by using the Content-ID value of those parts in their href attribute. The order of referenced MIME payload parts in the MIME envelope MAY differ from the order of corresponding eb:PartInfo elements in the ebMS3 eb:PayloadInfo header.
For each business process, for each exchange involving exchange of XML documents, a specification SHOULD be agreed that defines the XML schema definition (XSD) that the XML document is expected to conform to. The mapping from AS4 headers including eb:Service and eb:Action to XSDs SHOULD be unique, allowing Receivers to validate XML documents using a specific XML schema. Note that there is no requirement that any XML schema validation is done by the AS4 MSH.
While the AS4 protocol has no inherent limitation on message size, users SHOULD take into consideration the practical limits that are imposed by some AS4 implementations (e.g. the use of certain data types in some security libraries imposes a maximum size of approximately 2 GB) or by deployment contexts of AS4 implementations (e.g. amount of memory or storage available to the AS4 server).
Any additional profiling of payloads and message flows is out of scope for this specification.
Message exchange solutions are part of the overall IT service life-cycle, in which different environments are operated (often in parallel) for development, test, pre-production (in some companies referred to as "acceptance environments" or "QA environments") and production. Development and test are typically internal environments in which trading partners are simulated using stubs. When exchanging messages (in either pre-production or production environments), parties MUST target the appropriate environment. In order to prevent a configuration error from causing non-production messages to be delivered to production environments or vice versa, parties SHOULD configure processing modes at message handlers so that messages from one type of environment cannot be accepted inadvertently by a different type of environment.
This eDelivery AS4 profile MAY be deployed on IPv4 and/or IPv6 networking.
The following table summarizes the P-Mode settings as defined in this eDelivery Common Profile.
The eDelivery AS4 Common Profile MAY be enhanced with Profile Enhancements. This section specifies four such Profile Enhancements. The Profile Enhancements MUST be used in conjunction with the Common Profile. The four currently defined Profile Enhancements are mutually compatible, so they MAY be used in combination. However, this is NOT REQUIRED. Implementations MAY also limit support for one Enhancement to be used only in combination with another Enhancement. Future versions, or profiles, of this eDelivery AS4 Profile MAY specify additional Profile Enhancement modules.
Four Corner Topology
The OASIS ebMS3 and AS4 specifications are specifications for point-to-point message exchange between two Message Service Handlers. However, eDelivery AS4 is also used in situations where messages are exchanged by Access Points on behalf of other parties. In this so-called four corner topology, from an end-to-end perspective, there are four rather than two parties involved in the message exchange. Two parties are the original sender and final recipient parties. The other two parties are Access Points that route messages from the original sender to the final recipient and reverse route response messages. The four parties are conventionally referred to using Cn labels, where C stands for "corner" and the n is one of the digits 1 to 4:
The Four Corner Topology Profile Enhancement supports the use of eDelivery AS4 as a common solution to interconnect parties using Access Points. The Four Corner topology is typically used in situations where Access Points interconnect heterogeneous messaging domains, following the Messaging Bridge pattern:
However, this Profile Enhancement MAY also be used to identify distinct Producer and Consumer components, not involving the Messaging Bridge pattern. As the Common Profile applies to the C2-C3 exchange, the exchange involves an AS4 push from C2 as Initiator to C3 as Responder. The exchanges between C1-C2 and C3-C4 are NOT REQUIRED to use AS4 and are out of scope for this specification. Depending on the integration (e.g. store-and-forward, mailbox etc.), the transfer from C3 to C4 may be initiated by C3 or C4.
Addressing and Party Identification
This Enhancement to the Common Profile specifies the use of eDelivery AS4 in four corner message exchanges. It defines conventions for the use of ebMS3 message headers and configuration of the corresponding processing mode parameters.
For Message Packaging this Profile Enhancement constrains values for several elements in the AS4 message header and the overall message structure. In scenarios where AS4 is used for point-to-point communication between end entities, the eb:From and eb:To headers in the eb:UserMessage/eb:PartyInfo identify the Sender and Receiver respectively. In a four-corner-model, the Sender and Receiver of AS4 messages are the inner corner Access Points (C2, C3), not the outer corner parties (C1, C4). To facilitate the use of unmodified AS4 messaging implementations and to simplify configuration of AS4 message service handlers, eb:From/eb:PartyId and eb:To/eb:PartyId MUST identify the inner corner Access Points.
To be able to route a received message, the receiving Access Point (C3) needs to be able to determine the final recipient (C4). This information is generally available in a structured payload. However, using information from a structured payload assumes an understanding of the schema on which the payload is based. In order to allow Access Points to process payloads of any type, it is desirable to adopt a mechanism that is independent of particular schemas. Furthermore, in some situations there MAY be a requirement to route unstructured or encrypted data. This Profile Enhancement therefore uses the ebMS3 property mechanism to identify C1 and C4. The property mechanism allows the use of arbitrary property-value pairs in an AS4 message and is independent of payload format or structure.
When used in a Four Corner typology:
As with the eb:From/eb:PartyId and eb:To/eb:PartyId headers, the type attribute MAY be used with these two properties to categorize party identifier types. As identifier system and format for addressing, the ISO 6523 code MUST be used for party types registered in ISO 6523 and the ebCore Party ID format SHOULD be used as specified in [eDelivery-EBCORE].
This profile defines an additional, optional third property:
A key advantage of the use of ebMS3 message properties is that no constraints are imposed on message payload. It is possible to transport, route and forward any payload, or combination of payloads, even if unstructured, binary or encrypted.
When using the eDelivery AS4 Four Corner Topology Profile Enhancement:
These parameters are P-Mode parameters that can be set for individual P-Modes. A conformant MSH MAY be engaged in Four Corner Topology exchanges for some partners, or for some services, and not for others.
Relation to SOAP and ebMS3 intermediary concepts
In a Four Corner topology, when used as Messaging Bridge, the scope of AS4 as interconnect messaging protocol is limited to the interaction between the inner two corners (C2 and C3). This means that, in terms of the ebMS3 Messaging Model:
This exchange is not to be confused with the SOAP processing model as defined in SOAP 1.2, second edition [SOAP12]. SOAP intermediaries operate in a chain of SOAP processing nodes. In a Four Corner Typology, The C1-C2 and C3-C4 connections MAY be SOAP-based, but this is NOT REQUIRED.
The ebMS3 Part 2 “Multihop” module [EBMS3P2] uses the SOAP processing model to define a multihop messaging protocol based on ebMS3 SOAP intermediaries that forward ebMS3 SOAP messages. In that model there is no submission or delivery to the intermediary MSH and end-to-end security and reliability can be provided. The eDelivery AS4 Four Corner Typology Enhancement REQUIRES use of AS4 between inner nodes only and is not based on the ebMS3 multihop advanced feature. AS4 is NOT REQUIRED in the communication from and to the outer corners.
Note on Non-Repudiation
The use of XML Signature in WS-Security specified in the Common Profile provides Non Repudiation of Origin (NRO) at Message Exchange level. When using the Four Corner Topology enhancement, the origin is understood to be the AS4 sender C2. Any end-to-end Non Repudiation of Origin (NRO), providing content commitment for C1, is out of scope for this Profile Enhancement. This is a difference to the ebMS3 Part 2 “Multihop” module that does provide end-to-end NRO.
The use of signed AS4 Non Repudiation Receipts as specified in the Common Profile provides Non Repudiation of Receipt (NRR) at Message Exchange level. When using the Four Corner Topology enhancement, the receiver is understood to be the AS4 receiver C3. Any end-to-end Non Repudiation of Receipt (NRR), providing content commitment for C4, is out of scope for this Profile Enhancement. This is a difference to the ebMS3 Part 2 “Multihop” module that does provide end-to-end NRR.
For more information on this topic, see the Security Controls Guidance document [SECCONTROLS].
Standard Business Document Header (SBDH)
The eDelivery AS4 Common Profile MAY be used in conjunction with the UN/CEFACT Standard Business Document Header [SBDH]. SBDH is a standard XML format that encodes common message metadata, such as identification of sender and receiver, the type of the payload and the business scope, business process, business transaction, agreement, and business quality-of-service. SBDH is widely adopted in various domains.
When used in conjunction with AS4, the SBDH can be used in two ways:
Using a standalone SBDH instance
When used as a standalone XML document, the SBDH serves as a specialized XML payload, which can be seen as a kind of internal header. Other content parts do not need to be modified (e.g. base64 encoded) to be used with a standalone SBDH part, and are exchanged as additional separate message payload parts.
The standalone SBDH is most useful in conjunction with non-XML documents. In this case, the SBDH and the payload have to be in separate MIME parts because they have different content types: SBDH is XML and the payload non-XML. An example use of a non-XML business payload is the ETSI ASiC container specification [ASiC]. ASiC is a non-XML file format, which has the MIME content type application/vnd.etsi.asic-e+zip.
Like any AS4 payload part, the SBDH payload part and the additional message parts MUST be referenced from the ebMS eb:UserMessage header. The eb:UserMessage header uses the Content ID URI [RFC2392] in its eb:PayloadInfo section to reference other MIME parts in the same message as the referring MIME part. The SBDH references the additional message parts using the sh:Manifest element.
Identifiers and Cross-References in a MIME Envelope with ebMS3 Header and Standalone SDBH
The following table shows the identifiers of various parts of an AS4 messaging containing a standalone SDBH and one or more additional payloads. The MIME parts are all identified using a Content-ID header. The enveloping HTTP/MIME structure references the SOAP root MIME part using its start parameter. The ebMS3 header in the SOAP root part references the standalone SBDH header document payload and all other payloads from its eb:PayloadInfo structure. In this situation, the SBDH MUST be referenced using the first eb:PartInfo part reference and is considered the initial leading document. Any other payload parts MUST be referenced from the SBDH, in addition to being referenced from the AS4 header.
Note that, according to the WS-I Attachments Profile [AP], semantics should be neither given to, nor implied by the ordering of MIME parts in a message. The logical relations are established using part content identifiers and references using those identifiers only.
Note: for readability and formatting (line wrapping) reasons, the XPath expressions in this table have been edited to include spaces.
Standalone SBDH Example
The following example shows a sample standalone SBDH document. It uses an sh:Manifest block for referencing non-XML documents or files.
AS4 and XML Payloads using SBDH Headers
As an alternative to standalone use of SBDH, the SBDH can also be an integral part of an XML business document. When used with the eDelivery Common Profile, this business document, including its SBDH part, will be packaged in a single MIME part. There are many reasons why the implementer would choose an integrated packaging approach (SBDH as part of XML document) or a non-integrated approach (standalone SBDH). The following arguments favor the integrated approach:
An SBDH that is part of an XML business document that does not reference any attachments does not have a sh:Manifest element.
Using the SBDH in a Four Corner Topology
The SBDH Profile Enhancement MAY be used in conjunction with the Four Corner Topology Profile Enhancement. If, in a Four Corner context, the SBDH is used as a container for information relating to the "end to end" exchange, then the sh:Sender at SBDH level corresponds to the C1 original sender and the sh:Receiver corresponds to the C4 final recipient. In this situation, the values of the AS4 message properties specified in the Four Corner Topology Profile Enhancement can be populated and set in submission to the sending AS4 MSH, using values in the SBDH content. The consumer SHOULD validate that, for any message delivered to it, the values of the AS4 Four Corner message properties match the values of the corresponding SBDH values.
This mapping applies both in situations where the SBDH is a separate payload and in situations where it is an integral part of the leading business document.
If the exchange from the original sender (C1) to the sending Access Point (C2) and/or the exchange from the receiving Access Point (C3) to the final recipient (C4) is also based on AS4 or other messaging protocols that support exchanging multiple payloads using multipart/related MIME containers (such as ebMS2 or AS2), then all message payloads including the SBDH part and any cross-references between them based on Content-ID headers can be forwarded without loss of information.
Note that it is NOT REQUIRED to use the SBDH Profile Enhancement in conjunction with the Four Corner Topology Profile Enhancement. It MAY also be used in point-to-point exchanges.
AS4 Header and SBDH Comparison
The AS4 header is the ebMS3 eb:Messaging header which is part of the ebMS3 SOAP message. It is not a message payload and it is processed by the AS4 Message Service Handler. The format and content of the AS4 user message header are similar to the header structure defined in the earlier ebMS 2.0 standard. The header allows:
The following table provides a comparison between the AS4 Messaging Header and the SBDH, showing their functional similarity:
As the AS4 Header provides most SBDH features, the SBDH in many cases is not be needed.
In traditional B2B data exchange, parties interact with a known set of counterparties. Messaging implementations allow users to configure partners and message exchange parameters for these partners, such as signing and encryption certificates and endpoint URIs. Users update these configurations as partners are added or removed or any configuration parameter values change.
This optional Profile Enhancement relaxes this requirement for incoming messages and allows parties to configure their AS4 MSH to receive user messages from Sender parties that have not been registered in the Receiving MSH and for which the party identifier and signing certificate have not been pre-shared between Sender and Receiver. For party authentication and authorization, it specifies an X.509 PKI-based mechanism.
Unregistered Sender Party
When using a Push transport channel binding (as is always the case in the current version of eDelivery AS4 Common Profile), in a One Way exchange the Initiator Party is the Sender Party and the Responder Party is the Receiver Party. In ebMS3, the PMode.Initiator.Party parameter is stated to be optional if the PMode.Responder.Party parameter is specified [EBMS3]. The PMode.Responder.Party parameter is always configured for a P-Mode for One Way incoming user messages deployed at the Receiver party MSH.
In the Dynamic Receiver Profile Enhancement, for a One Way exchange the PMode.Initiator.Party parameter MUST NOT be set in the Receiver MSH for P-Modes that are to be used to dynamically process messages from unregistered Senders. This mechanism is needed to allow a Receiving MSH to handle One Way messages from multiple Sender Parties using a single P-Mode or P-Mode template. Implementations MAY have additional mechanisms, out of scope for this specification, to configure that a P-Mode is to be used, or is not be used, dynamically with unregistered parties.
Section 4.3.5 extends this feature to Two Way exchanges.
X.509 PKI-based Authentication and Authorization
In ebMS3, it is stated that the PMode.Security.X509.Signature.Certificate "identifies the public certificate to use when verifying signed data". In the case of unregistered senders, the leaf signing certificate of the Sender Party may not be available to the Receiver Party before the first message that uses the certificate is transmitted to it. Therefore, this Profile Enhancement requires the Receiver MSH to instead configure:
As the receiver MAY not have pre-configured the signing leaf certificate, a BinarySecurityToken token reference MUST be used to reference the signing certificate.
A Receiving MSH that implements this Profile Enhancement, when processing a message from an unregistered Sender Party under control of a Dynamic Receiver P-Mode, MUST verify the following constraints:
Authentication of the message fails if any of these constraints are not met, in which case the Receiving MSH MUST NOT accept the AS4 message.
Note that these requirements may not (or not just) be Usage Profile conventions that users deploying AS4 implementations are expected to observe, but may require either specific built-in functionality in the AS4 MSH, or some separate mechanism that provides just-in-time updates of the AS4 configuration.
Also note that this Profile Enhancement does not preclude implementations from providing additional authorization checks (for example, using white-listing or black-listing at party or service level) to control which parties can and cannot send messages to them. However, any such mechanisms are out of scope for this specification.
For One Way exchanges, the following P-Mode parameters are affected by this Profile Enhancement:
These parameters are P-Mode parameters that can be set for individual P-Modes. A conformant deployed MSH MAY be a Dynamic Receiver for some exchanges and not for others.
Dynamic Receiver in Two Way Exchanges
A Two Way exchange consists of two legs (a request leg and a response leg). The party that is the Sender in the first (request) leg is the Receiver in the second (response) leg and vice versa. For Two Way exchanges, the Receiver MSH that implements the Dynamic Receiver Profile Enhancement and that is the Responding Party processes the first leg as it processes a One Way message.
The processing by an MSH that is the Receiver MSH for messages received on the second leg of Two Way exchange is similar to processing One Way exchanges, except that in the second leg of a Two Way exchange the Receiving MSH is the Initiator and the Sender Party corresponds to the PMode.Responder.Party parameter. The PMode.Responder.Party parameter is optional if the PMode.Initiator.Party parameter is specified [EBMS3]. The affected P-Mode Parameters are therefore as specified in section 4.3.4, except that the PMode.Responder.Party is affected instead of the PMode.Initiator.Party.
Note that when an MSH receives a second leg response message from another MSH, it will (by the definition of Two Way exchanges) have previously sent a message to that other MSH. It MAY have used the Dynamic Sender Profile Enhancement and accessed a discovery infrastructure to send the first leg request. So by the time that previously unknown Responder MSH returns a response message, it may have become a registered Sender.
Relation to other Profile Enhancements
The separate Dynamic Sender Profile Enhancement is similar to this Dynamic Receiver Profile, but is concerned with outgoing messages, whereas this Dynamic Receiver Enhancement is concerned with incoming messages. The two Profile Enhancements are complementary and MAY be used in a single AS4 deployment. However, this is NOT REQUIRED.
This profile MAY be used in conjunction with the Four Corner Topology Profile Enhancement by an Access Point acting, as a C3, as a receiver of AS4 messages. However, this Profile Enhancement MAY also be used in point-to-point exchanges.
This Profile Enhancement supports exchanges with or without SBDH.
Sample Use Case
As an example, the eDelivery AS4 Dynamic Receiver Profile Enhancement could be used in a star topology, in which one party acts as a central hub to receive data from a large (and possibly dynamic) number of counterparties, which do not communicate directly with each other. In this case, all counterparties could have a single, fixed configuration for communication with the hub, not using any of the four Profile Enhancements defined in this specification. The hub could also have a single configuration, taking advantage of the Dynamic Receiver Profile Enhancement to simplify the configuration of its AS4 MSH, while still accepting messages from multiple counterparties.
While this Profile Enhancement addresses the requirements of some user communities, it has some important limitations:
In traditional B2B data exchange, parties interact with a known set of counterparties. Messaging implementations allow users to configure partners and message exchange parameters for these partners, such as signing and encryption certificates and endpoint URIs. Users can update these configurations, as and when partners are added or removed or their configurations change.
This optional Profile Enhancement relaxes this requirement for outgoing messages and allows parties to configure their AS4 MSH to send user messages to Receiver parties that have not been pre-configured. For these parties, the party identifier and AS4 protocol parameters (such as the party's encryption certificate and the address of its AS4 server endpoint) are not registered in the Sending MSH. The Profile Enhancement provides a mechanism by which P-Modes can be created dynamically and deployed on an ad hoc basis, by instantiating templates using additional parameters supplied by the Producer and data retrieved using queries on a discovery infrastructure.
This Profile Enhancement supports two modes of operation:
Note that a conformant deployed MSH MAY be a Dynamic Sender for some services and not for others.
Dynamic P-Modes and Discovery
This Profile Enhancement defines an ability of a Sending AS4 MSH, or a communication system that includes an AS4 MSH and exposes a similar Submit operation to Producers, to dynamically instantiate a P-Mode for a submitted outbound message using a P-Mode template, a number of input parameters and information obtained from a discovery infrastructure. The term P-Mode template is used informally to refer to an abstract incomplete AS4 Processing Mode that needs to be extended with some additional parameters to be ready for actual data exchange.
Note that, like the concept of Processing Modes in ebMS3, this specification uses the term P-Mode template as an abstract concept only. It does not intend to constrain any particular implementation options for AS4 implementations.
The Dynamic Sender Profile Enhancement MAY be implemented in a layer between Producer and the AS4 MSH. This is possible as the eDelivery AS4 Common Profile, section 3.2.7, REQUIRES implementations to provide an API to create and deploy P-Modes. This API can be used to deploy a P-Mode that has been constructed using information obtained from the discovery infrastructure. This allows any AS4 implementation that supports the eDelivery AS4 Common Profile to implement the Profile Enhancement. Alternatively, the functionality of the Profile Enhancement MAY be implemented internally in the AS4 MSH directly.
Discovery Infrastructure Requirements
For the eDelivery AS4 Common Profile, the Discovery Infrastructure MUST return information for the following parameters, for a One Way Exchange.
This Profile Enhancement is independent of any specific discovery infrastructure, as long as the infrastructure is able to meet the specified functional requirements.
Dynamic Sender in Two Way Exchanges
In a Two Way exchange, the Dynamic Sender Profile Enhancement applies to the first leg as specified in the preceding sections. For the second leg, which in the eDelivery Common Profile is a separate Push exchange, the reverse process is very similar: the Consumer submits a response message to the Responder MSH (or to any component that includes the Responder MSH responsible for Dynamic Sender processing), which among others:
The discovery infrastructure is used to determine the PMode.Protocol.Address, PMode.Security.X509.Encryption.Certificate and PMode[s].Security.X509.Signature.Certificate parameters.
Relation to other Profile Enhancements
The separate Dynamic Receiver Profile Enhancement is similar to this Dynamic Sender Profile Enhancement, but is concerned with incoming messages, whereas this Dynamic Sender Profile Enhancement is concerned with outgoing messages. The two Profile Enhancements are complementary and MAY be used in a single AS4 deployment.
If the discovery infrastructure does not support discovery of the X.509 certificate that the Responder MSH will use to sign AS4 receipts or errors, the Initiating MSH SHOULD implement the Dynamic Receiver Profile Enhancement to validate the AS4 signal and the signing certificate used.
This profile MAY be used in conjunction with the Four Corner Topology Profile Enhancement by an Access Point acting, as a C2, as a sender of AS4 messages for discovery of the C3 for a C4 final recipient. However, this Profile Enhancement MAY also be used in point-to-point exchanges.
This Profile Enhancement supports exchanges with or without SBDH as specified in the Standard Business Document Header (SBDH) Profile Enhancement.
Sample Use Case
The Dynamic Sender Profile Enhancement could be implemented by a service provider in an open network of service providers that offers a discovery infrastructure. Customers of the service provider can submit messages that are to be sent to any party for which the receiver service provider and a Receiving MSH AS4 communication configuration can be discovered.
While this Profile Enhancement addresses the requirements of some user communities, it has some important limitations:
The following (non-normative, edited) example contains an AS4 message from a Seller to a Buyer in an e-procurement scenario involving the exchange of an XML order response document. It implements the Common Profile and the Four Corner Typology Profile Enhancement.
This section defines six Conformance Clauses.
eDelivery AS4 Common Profile Conformance Clause
In order to confom to the eDelivery AS4 Common Profile, an implementation MUST conform to all normative statements and requirements in section 3. In particular, it MUST:
This Conformance Clause is adapted from the AS4 ebHandler Conformance Clause, specified in section 6.1 of [AS4].
eDelivery AS4 Four Corner Topology Conformance Clause
In order to conform to the eDelivery AS4 Four Corner Conformance Clause, an implementation MUST:
eDelivery AS4 SBDH Conformance Clause
In order to conform to the eDelivery AS4 Four Corner Conformance Clause, an implementation MUST:
eDelivery AS4 Dynamic Receiver Conformance Clause
In order to conform to the eDelivery AS4 Dynamic Receiver Conformance Clause, an implementation MUST:
eDelivery AS4 Dynamic Sender in Point-to-Point Exchanges Conformance Clause
In order to conform to the eDelivery AS4 Dynamic Sender Conformance Clause, an implementation MUST:
eDelivery AS4 Dynamic Sender in Four Corner Exchanges Conformance Clause
In order to conform to the eDelivery AS4 Dynamic Sender Conformance Clause, an implementation MUST:
The AS4 Profile of ebMS 3.0 Version 1.0 technical specification is Copyright © OASIS Open 2013. All Rights Reserved. The AS4 Profile of ebMS 3.0 Version 1.0 technical specification is created by the OASIS ebXML Messaging Services Technical Committee which operates under the RF on Limited Terms Mode of the OASIS IPR Policy.
AS4 is based on the OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features OASIS Standard, which is Copyright © OASIS ® 1993–2007. All Rights Reserved. The ebMS 3.0 Standard uses the SOAP protocol. The IPR declaration of SOAP submitters to W3C is available from http://www.w3.org/Submission/2000/05/.
Parts of the implementation guidelines in this specification are derived, with permission, from parts of the ENTSOG AS4 Profile for TSOs. ENTSOG can be contacted at http://www.entsog.eu/publications/data-exchange.
Parts of the implementation guidelines in this specification, in particular the Four Corner Enhancement, are derived, with permission, from e-CODEX specifications [ECODEXD5.11] . E-CODEX can be contacted as follows:
Ministry of Justice NRW, Martin-Luther-Platz 40 - 40212 Düsseldorf (GERMANY).
All other content of this specification, up to version 1.11, was created in the former EU e-SENS project. The e-SENS project completed in March 2017. The EU e-SENS project formally transferred ownership of its specifications to the European Commission, which accepted it for further maintenance in the context of the CEF Programme.
The Dynamic Receiver and Dynamic Sender Profile Enhancements introduced in section 1.13 are derived from the e-SENS SMP implementation guidelines which are derived from PEPPOL specifications.
Information on governance and procedures for eDelivery is available from Governance and Procedures.
[AES] Advanced Encryption Standard. FIPS 197. NIST, November 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
The CEF eDelivery team is in charge of maintaining the current version of the specifications.
Details about contributors of previous versions of this specification can be consulted on the e-SENS website.
Details about previous versions of the specifications can be consulted on the e-SENS website.