1. Description

The eDelivery AS4 Profile is a modular profile of the ebMS3 and AS4 OASIS specifications, now also standardized as parts one and two of the ISO 15000 series. 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, Dynamic Receiver and Dynamic Sender behavior, support for the Pull feature, for the ebMS3 Part 2 Large Message Split and Join feature, use of the ebCore Agreement Update protocol and for alternative security algorithms.

This major version 2.0 specification is not compatible with previous versions as it uses incompatible security algorithms.

2. Base specifications

This specification is based on the following OASIS specifications:

• [AS4] AS4 Profile of ebMS 3.0 Version 1.0. OASIS Standard, 23 January 2013. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/. This specification has been standardized as [ISO 15000-2].

• [EBMS3] OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features. OASIS Standard, 1 October 2007. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/. This specification has been standardized as [ISO 15000-1].

2.1. Features

The following table summarizes the features provided by the ebMS3 and AS4 specifications. The eDelivery profile is a profiled extended subset of these features of the AS4 specification.

Table 1. ebMS3/AS4 Functional Overview. (*) in ebMS3, not in AS4 (**) AS4 extension to ebMS3

2.2. Benefits

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:

• Payload agnosticism: document or data types (e.g. purchase order, invoice, XML, PDF etc.) are not tied to any defined SOAP action or operation;
• Support for single or multiple payloads contained either within the SOAP body or as SOAP (MIME) attachment(s);
• Support for the ebMS 3.0 One-Way/Push message exchange pattern with support for either synchronous or asynchronous signal responses;
• Support for the ebMS 3.0 One-Way/Pull message exchange pattern, which is beneficial for exchanges with non-addressable endpoints;
• Reception Awareness features and Duplicate Detection capabilities make use of the eb:Receipt as the sole type of acknowledgment.

Note that this version of this eDelivery AS4 specification does not use all features of ebMS3 and AS4. For a complete feature list, see section 3.2.

2.3. Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] ([RFC2119] and [RFC8174]) when, and only when, they appear in all capitals, as shown here.

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[1], orAS4 ebHandler Conformance Profile that are specified separately for the user messages in the two legs in a Two Way exchange, i.e. PMode[1] and PMode[2]. 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].

3. Common Profile

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 and profiles the AS4 Usage Rules. 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 2.0 version updates the security section by adopting more state-of-the art protocols and algorithms. The original eDelivery AS4 Common Profile was the same as the ENTSOG profile, for general AS4 messaging aspects. The security updates for the 2.0 version are again developed in close cooperation with ENTSOG and other AS4 user groups.

3.1. 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.

3.2. 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:

• There is an added requirement to support Two Way MEPs.
• Transport Layer Security is mandatory and may be handled in the AS4 handler or in an infrastructure component, such as a reverse proxy. If handled in the AS4 handler, its use is profiled.
• WS-Security is mandatory and the WS-Security specification version is the 1.1.1 version.
• Algorithms specified for securing messages at the Message Layer are updated to current guidelines and use of signing and encryption is mandatory using specific algorithms.
• Support for IPv4 and IPv6 is explicitly required.

It also relaxes some requirements:

• Support for Pull mode in AS4 is not required in this version of Common Profile.
• All payloads are exchanged in separate MIME parts, never in the SOAP Body.
• Receipts and errors are reported synchronously only.
• WS-Security support is limited to the X.509 Token Profile. The use of UserName Tokens is not supported.

Note that, while the Pull feature is not part of the eDelivery Common Profile, it is available as an optional Profile Enhancement.

3.2.1. Message Exchange Patterns

The following paragraphs summarize some key concepts and terminology defined in the ebMS 3.0 core specification [EBMS3]:

1. Messaging Service Handler (MSH), Producer, Consumer. An MSH is an entity that is able to generate or process messages that conform to the ebMS specification, and to act as sender or receiver. A Producer is an entity (e.g. application) that interacts with a Sending MSH (i.e. an MSH in the Sending role) to initiate the sending of a user message. A Consumer is an entity that interacts with a Receiving MSH (i.e. an MSH in the Receiving role) to consume data from a received user message.
2. Message, User Message, Signal Message. A Message is a logical unit which consists of User Messages or Signal Messages or both. A User Message is a message that contains a User Message unit (an eb:Messaging/eb:UserMessage XML structure). A Signal Message is an ebMS message that contains a Signal Message unit (an eb:Messaging/eb:SignalMessage XML structure). In other words, there exist two types of messages in the ebMS specification: the first type allows transmitting data interpreted by a Consumer and the second type allows transmitting data interpreted by an MSH as a signal (e.g. a pull signal, receipt or error).
3. Message Exchange Pattern (MEP), One-Way/Push, One-Way/Pull, Two-Way/Sync MEP. An MEP is an agreement between sending and receiving MSHs. Some aspects of MEPs supported in the messaging layer include:
   • Specifying the correlation between messages sent and received in the message header.
   • Message binding to the underlying transfer-protocol.
   One-Way/Push, One-Way/Pull and Two-Way/Sync MEPs describe agreements between MSHs.
4. Processing Mode (P-Mode) - A P-Mode is the contextual information that governs the processing of a particular message (thus is basically a set of configuration parameters). The P-Mode associated with a message determines, among other things, which security and/or which reliability protocol and parameters, as well as which MEP is being used when sending a message. The technical representation of the P-Mode configuration is implementation-dependent.

The Messaging Model of the AS4 profile constrains the channel bindings of message exchanges between two AS4 MSHs. The following diagram shows the AS4 Messaging Model, various actors and operations in message exchange:

 
Figure 1. Entities of the AS4 Messaging Model and their Interactions [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:

• One Way / Push
• Two Way / Push-and-Push

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:

• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay

For PMode.MEPbinding, support is required for:

• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/push
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pushAndPush

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.

Note that, while the Pull feature is not part of the eDelivery Common Profile, it is available as an optional Profile Enhancement.

3.2.2. 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.

 
Figure 3. AS4 Message Structure, UserMessage.

The SOAP envelope SHOULD be encoded as UTF-8 (see [EBMS3], section 5.1.2.5). 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:

• set the value for eb:ConversationId. This enables the Consumer to correlate the user message to related user messages that are part of the same conversation.
• set the value for eb:RefToMessageId, for business response messages in a Two WAY MEP. This allows the Consumer to indicate to which previous AS4 request user message the user message is a response. Note that a shared value for eb:ConversationId is not sufficient for correlating requests and responses as there may be more than one outstanding request in a single conversation.

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 MSH allows the Producer to specify, when submitting the user message unit, a specific value to be used for eb:MessageId.
• The MSH generates the eb:MessageId value, and then notifies the Producer of the generated value.

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.

3.2.3. Packaging Payloads

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 2.2.3.3), 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 5.2.2.12 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.

3.2.4. Test Service

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:

• eb:UserMessage/eb:CollaborationInfo/eb:Service set to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service

• eb:UserMessage/eb:CollaborationInfo/eb:Action set to http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/test

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.

3.2.5. Error Handling

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 parameter PMode[].ErrorHandling.Report.AsResponse MUST be set to the value true.
• The parameter PMode[].ErrorHandling.Report.ProcessErrorNotifyConsumer SHOULD be set to the value true.
• The parameter PMode[].ErrorHandling.Report.ProcessErrorNotifyProducer SHOULD be set to the value true.

The AS4 option to transmit errors using asynchronous messages MUST NOT be used.

Error messages SHOULD be signed.

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.

3.2.6. Security

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 are therefore out of scope for this sub-section. In this AS4 profile, message exchange MUST be secured using both transport layer security and message layer security. Transport layer security 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 the publication of this specification, previously unknown vulnerabilities may be discovered in the security algorithms, formats, and exchange protocols specified in this section. Such discoveries MUST lead to revisions of this specification.

3.2.6.1. Transport Layer Security

When using AS4, Transport Layer Security (TLS) provides content 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.

TLS can be directly handled by the AS4 message handler or be offloaded to some infrastructure component. In the following, we refer to the TLS processing component as TLS implementation. For every TLS implementation conformant with this profile, the following rules shall apply:

• TLS versions and cipher suites MUST follow international and national minimum standard requirements and best practices such as [ECRYPT CSA], [NIST 800-52r2], [BSI TR-02102-2] and [RFC9325]. The decision which, if any, of these publications to follow is not specified in this profile as it may depend on other international, national and/or sectorial regulation or other factors.
• It MUST be possible to configure the accepted TLS version(s) in the TLS implementation.
• It MUST be possible to configure accepted TLS cipher suites in the TLS implementation. Note that naming conventions and recommendations for suites are specific to TLS versions.

3.2.6.1.1. TLS versions

Implementations conformant with this profile:

• MUST NOT use SSL 3.0, TLS 1.0 and 1.1.
• MUST therefore at a minimum support TLS 1.2 [RFC5246]. TLS 1.2 is considered sufficient and offers good cryptographic primitives. With proper configuration of cipher suites it is considered sufficient for many years.
• SHOULD support the use of TLS 1.3 [RFC8446]. Note that [NIST 800-52r2] requires support for TLS 1.3 as from January 1, 2024.

3.2.6.1.2. TLS cipher suites

Implementations conformant with this profile SHOULD support the following TLS 1.3 cipher suites:

• TLS_AES_128_GCM_SHA256 
• TLS_AES_256_GCM_SHA384
• TLS_AES_128_CCM_SHA256

These cipher suites are recommended by [BSI TR-02102-2] and [NIST 800-52r2]. Note that [ECRYPT CSA] does not make any explicit restrictions regarding TLS 1.3 cipher suites. [RFC9325] recommends to follow the recommendations from [RFC8446].

In addition, TLS_CHACHA20_POLY1305_SHA256 may be used [RFC8446].

For TLS 1.2, this profile recommends the usage of Perfect Forward Secure (PFS) cipher suites. Implementations conformant with this profile SHOULD support the following TLS 1.2 cipher suites:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CCM
• TLS_ECDHE_ECDSA_WITH_AES_128_CCM
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

These cipher suites are compatible with the recommendations of [BSI TR-02102-2], [NIST 800-52r2], [ECRYPT CSA] and [RFC9325].

Further cipher suites may be used when following specific regulations. For example, [ECRYPT CSA] recommends the usage of Camellia for record layer encryption. [BSI TR-02102-2], [NIST 800-52r2], and [ECRYPT CSA] recommends the usage of TLS_DHE_* cipher suites.

3.2.6.1.3. Supported Groups for (EC)DH Key Exchange 

Implementations conformant with this profile should support the following elliptic curves:

• secp256r1
• secp384r1
• secp521r1
• x25519
• x448

When using Finite Field Diffie Hellman, at least ffdhe3072 should be used.

3.2.6.1.4. Certificate Key Lenghts

Implementations conformant with this profile MUST use RSA, ECDSA, or EdDSA X.509 certificates. For RSA certificates, keys larger than 3000 bits are mandatory. For ECDSA, keys larger than 250 bits are REQUIRED.

3.2.6.1.5. TLS Client Authentication

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.

3.2.6.2. Message Layer Security

3.2.6.2.1. Use of WS-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]:

• Web Services Security SOAP Message Security [WSSSMS].
• Web Services Security X.509 Certificate Token Profile [WSSX509].
• Web Services Security SOAP Message with Attachments (SwA) Profile [WSSSWA].

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]).

3.2.6.2.2. Message Signing

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. In addition, Ed25519 and Ed448 algorithms are available based on [RFC8410] and [RFC9231]. This eDelivery AS4 profile anticipates an update to the OASIS AS4 specification to reference these newer XML security specifications.

This AS4 profile uses the following AS4 parameters and values:

• The PMode[].Security.X509.Sign parameter MUST be set in accordance with section 5.1.4 and 5.1.5 of [AS4].
• The PMode[].Security.X509.Signature.HashFunction parameter MUST be set to http://www.w3.org/2001/04/xmlenc#sha256.
• The PMode[].Security.X509.Signature.Algorithm parameter MUST be set to http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519.

The use of XML Signature in AS4 provides Non Repudiation of Origin (NRO) at Message Exchange level.

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 wsse:BinarySecurityToken is the most widely implemented option for security token references in AS4 implementations, implementations SHOULD implement this option. To allow certificate chain validation, the ValueType attribute SHOULD be set to the X509PKIPathv1 URI.

A sending AS4 MSH performs security processing and constructs the ds:Signature header as follows:

1. The message parts that are to be signed (header, empty body and MIME parts) are selected in accordance with AS4.
2. Message digests are computed for all parts following [WSSSWA] using http://www.w3.org/2001/04/xmlenc#sha256. A ds:SignedInfo section is created that contains a ds:Reference element for each signed message part containing the respective message digest value.
3. The message is signed using sender’s signing key, determined from the applicable P-Mode using the http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519 algorithm.
4. The signature related security headers are placed under a ds:Signature element.

The receiving AS4 MSH processes the secured message containing this security header as follows:

1. Once the message parts have been decrypted successfully, the recipient processes the ds:Reference elements. It recalculates the digests for the signed parts and validates that their digest values match the specified values.
2. It then validates the signature value by using the public key from the sender certificate.

Note that the usage of the Ed25519 curve implies that the message signer has an EdDSA certificate using the Ed25519 curve for the subject key. This certificate is signed by an issuer that might use a different signing algorithm (RSA or ECDSA). This profile does not constrain the algorithms that certificate issuers use to sign issued certificates.

3.2.6.2.3. Message Encryption

For encryption, WS-Security leverages the W3C XML Encryption recommendation.This eDelivery AS4 profile anticipates an update to the OASIS AS4 specification to reference the newer XML security specifications [RFC6931] and [RFC9231] and its upcoming successor [RFC9231bis].

The following AS4 processing mode parameters configure this feature:

• The PMode[].Security.X509.Encryption.Encrypt parameter MUST be set in accordance with section 5.1.6 and 5.1.7 of [AS4].
• The parameter PMode[].Security.X509.Encryption.Algorithm MUST be set to http://www.w3.org/2009/xmlenc11#aes128-gcm. This is the algorithm used as value for the Algorithm attribute of xenc:EncryptionMethod in xenc:EncryptedData. This means that in this profile, AES MUST NOT be used in CBC mode.

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 at message layer. Note that this header remains encrypted at transport layer.

In this version of this AS4 profile, message encryption is based on the X25519 key agreement algorithm as specified in section 5.6 of [XMLENC1].

• For the key agreement method http://www.w3.org/2021/04/xmldsig-more#x25519 MUST be used. This is the algorithm used as value for the Algorithm attribute of xenc:AgreementMethod in ds:KeyInfo.
• When using X25519 public keys, the originator key info is included as a dsig11:DEREncodedKeyValue element. The ASN.1 content of that element references the OID 1.3.101.110 for X25519.
• To derive the AES 128 data encryption key, the http://www.w3.org/2021/04/xmldsig-more#hkdf algorithm defined in RFC 9231 is used on the agreed shared secret. This identifier is used as a value for the Algorithm attribute of xenc11:KeyDerivationMethod in xenc:AgreementMethod.

A sending AS4 MSH performs security processing and message encryption as follows:

1. For key agreement related information, an xenc:AgreementMethod element is created.
2. The sender generates an ephemeral X25519 key pair. The public key MUST be DER-encoded and placed in a dsig11:DEREncodedKeyValue element in the xenc:OriginatorKeyInfo sub-element of xenc:AgreementMethod.
3. The recipient's static public key information is determined from the applicable P-Mode. It is identified in a ds:KeyValue element placed in the xenc:RecipientKeyInfo sub-element of xenc:AgreementMethod.
4. A shared secret is constructed from the sender and recipient keys using X25519 key agreement.
5. The sender uses HKDF, http://www.w3.org/2021/04/xmldsig-more#hkdf, to derive an encryption key from the shared secret, a Salt, and an Info value. For hashing it uses the http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 algorithm. The length of the key is 16 bytes. The HKDF parameter information is placed under xenc:AgreementMethod in a dsig-more:HKDFParams sub-element.
6. A random AES symmetric key is generated and used to encrypt the MIME payload parts using the http://www.w3.org/2009/xmlenc11#aes128-gcm algorithm following [WSSSWA].
7. The AES key created in step 6 is wrapped using the derived key created in step 5 using the http://www.w3.org/2001/04/xmlenc#kw-aes128 algorithm.
8. The constructed xenc:AgreementMethod element is placed under a ds:KeyInfo element under an xenc:EncryptedKey element.
9. An xenc:EncryptedData element is added for each encrypted part as a child of the wsse:Security element.
10.  In each of these xenc:EncryptedData elements the encrypted key is referenced by using its identifier as the value of the URI attribute of a wsse:Reference in a wsse:SecurityTokenReference sub-element.
11. An xenc:ReferenceList is added under the xenc:EncryptedKey element listing the encrypted parts using their identifiers.
12. The xenc:EncryptedKey element is in turn placed as a child of the wsse:Security element.

Note that this eDelivery AS4 profile anticipates the dsig-more:HKDFParams element proposed in [RFC9231bis].

After message encryption, the xenc:EncryptedKey element representing the encryption key information and the xenc:EncryptedData elements representing the encrypted data are available for processing in the wsse:Security header and the MIME part content is encrypted.

The receiving AS4 MSH processes the secured message containing these two encryption related security headers as follows:

1. It identifies the xenc:ReferenceList in the xenc:EncryptedKey element and the xenc:EncryptedData elements to find the parts that are to be decrypted.
2. For each xenc:EncryptedData element, using the wsse:SecurityTokenReference, it finds the encryption key reference information.
3. In the referenced xenc:EncryptedKey element it processes the xenc:AgreementMethod element in the ds:KeyInfo. Using the xenc:OriginatorKeyInfo public key value and the private key identified by xenc:RecipientKeyInfo, it performs the ephemeral-static X25519 key agreement to obtain the X25519 shared secret key.
4. Using the shared secret key and the HKDF parameters specified on the dsig-more:HKDFParams element, it can unwrap the AES symmetric encryption key needed to decrypt the data.
5. With this key, it uses AES-GCM to decrypt data referenced in xenc:EncryptedData.

The Common Profile uses X25519 in so-called ephemeral-static mode: the sender creates an a shared secret key based on a short-lived sender key agreement key in combination with a long-lived recipient key agreement key configured as part of the AS4 P-Mode and unique random values for the Salt and Info key derivation parameters. The Common Profile does not mandate any mechanism for P-Mode configuration management. The recipient key agreement key MAY be configured using a management interface provided by the AS4 MSH product, updated using ebCore Agreement Update messages (see section 4.7 below) or retrieved from a discovery infrastructure (see section 4.4 below).

When using HKDF, applications SHOULD use random (or pseudo-random) salts as they contribute significantly to the security of HKDF. The Info parameter MAY be left empty, set to an application specific value or set to another random (or pseudo-random) value.

Note that X25519 keys can only be used for key agreement, not for signing. It is therefore not possible to create self-signed certificates or certificate signing requests for X25519. It is possible to convert an Ed25519 private/public key to X25519 private/public key. It is also possible for a party to create an Ed25519 key pair and an X25519 key pair and use the former to sign the latter.

3.2.6.3. Security Header Processing Example

A sample WS-Security header covering signing and encryption might look as follows:

<?xml version="1.0" encoding="UTF-8"?>
<wsse:Security xmlns:env="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:dsig-more="http://www.w3.org/2021/04/xmldsig-more#"
    xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" 
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
    env:mustUnderstand="true">
    
    <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
        wsu:Id="EK-6263cc2e-e01a-4bd2-a2f3-39f9c74e82ab">
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <xenc:AgreementMethod Algorithm="http://www.w3.org/2021/04/xmldsig-more#x25519">
                <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2021/04/xmldsig-more#hkdf">
                    <dsig-more:HKDFParams>
                        <dsig-more:PRF
                            Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
                        <dsig-more:Salt>xWdTey4T6awUJkp0NPZNVTa2JQkWukC0Uk+qaeEpn4Y=</dsig-more:Salt>
                        <dsig-more:Info>dGVzdC1pbmZvLWRhdGE=</dsig-more:Info>
                        <dsig-more:KeyLength>16</dsig-more:KeyLength>
                    </dsig-more:HKDFParams>
                </xenc11:KeyDerivationMethod>
                <xenc:OriginatorKeyInfo>
                    <dsig11:DEREncodedKeyValue>
                        MCwwBwYDK2VuBQADIQBf3vfsPjIizIMXS0Z5ombgWtKPLXpTMpV1QQW2ytMLLw==
                    </dsig11:DEREncodedKeyValue>
                </xenc:OriginatorKeyInfo>
                <xenc:RecipientKeyInfo>
                    <ds:KeyValue>
                        <!-- Assumes the recipient key is/has been shared as a certificate and can be
                            referenced using its SKI. -->
                        <wsse:SecurityTokenReference
                            xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                            <wsse:KeyIdentifier
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"
                                > ENCODED </wsse:KeyIdentifier>
                        </wsse:SecurityTokenReference>
                    </ds:KeyValue>
                </xenc:RecipientKeyInfo>
            </xenc:AgreementMethod>
        </ds:KeyInfo>
        <xenc:CipherData>
            <xenc:CipherValue>1OygswQnDMJi8AUWzoMhIuyyE/GjfHY3</xenc:CipherValue>
        </xenc:CipherData>
        <xenc:ReferenceList>
            <xenc:DataReference URI="#ED-ad394cf3-a2c0-442e-9943-f01cea6782cb"/>
        </xenc:ReferenceList>
    </xenc:EncryptedKey>     
    
    <xenc:EncryptedData 
        Id="ED-ad394cf3-a2c0-442e-9943-f01cea6782cb" MimeType="application/gzip"
        Type="http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Content-Only">
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm"/>
        <ds:KeyInfo>
            <wsse:SecurityTokenReference
                wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey">
                <wsse:Reference URI="#EK-6263cc2e-e01a-4bd2-a2f3-39f9c74e82ab"/>
            </wsse:SecurityTokenReference>
        </ds:KeyInfo>
        <xenc:CipherData>
            <xenc:CipherReference URI="cid:1400668830234@seller.eu">
                <xenc:Transforms>
                    <ds:Transform xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                        Algorithm="http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Ciphertext-Transform"
                    />
                </xenc:Transforms>
            </xenc:CipherReference>
        </xenc:CipherData>
    </xenc:EncryptedData>
    
    <wsse:BinarySecurityToken
        EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
        ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
        wsu:Id="X509-48b6d459-777b-4226-81bd-df327f37b30c"
        > ENCODED 
    </wsse:BinarySecurityToken>
    
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        Id="SIG-adcdc058-ddac-4437-8902-ab37cf037ca4">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                    PrefixList="env"/>
            </ds:CanonicalizationMethod>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519"/>
            <ds:Reference URI="#_840b593a-a40f-40d8-a8fd-89591478e5df">
                <!-- The (empty) SOAP body -->
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>jyTXyVrh+cX3iJzgmxqiHdnnJQxcX6kTGHPES1YUYEs=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference URI="#_210bca51-e9b3-4ee1-81e7-226949ab6ff6">
                <!-- the AS4 eb:Messaging header -->
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>5RMz5/mSIFTI1+amk+XLHsLR2yE7h5KFgAsLrHrya98=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference URI="cid:1400668830234@seller.eu">
                <!-- A message payload in a MIME attachment -->
                <ds:Transforms>
                    <ds:Transform
                        Algorithm="http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Content-Signature-Transform"
                    />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>wVgT8wKEsJlO0O5OjjQB/vw9mGsxi1n/0dc9qeRqFM4=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>CyVaSr9BLh7m4KC7xNszOsmJNM6aNJPKwQwNNqY5cvu3GgSIYBQWecg==</ds:SignatureValue>
        <ds:KeyInfo Id="KI-29066baf-2595-444f-9d27-58667dc40da3">
            <wsse:SecurityTokenReference wsu:Id="STR-a54b721a-0d19-4112-b1cf-06752cd826fa">
                <wsse:Reference URI="#X509-48b6d459-777b-4226-81bd-df327f37b30c"
                    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                />
            </wsse:SecurityTokenReference>
        </ds:KeyInfo>
    </ds:Signature>
</wsse:Security>

3.2.7. Configuration Management

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.

3.2.8. Networking

Conformant implementations MUST support IPv4 and IPv6 networking.

3.3. 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.

3.3.1. Compression

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:

• Message layer security processing, as there is less data to be signed/validated and encrypted/decrypted.
• Transmission of data over networks, as the message is smaller.

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.

<eb:Property name="CompressionType">application/gzip</eb:Property>

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.

Packaging requirements:

• An eb:PartInfo/eb:PartProperties/eb:Property/@name attribute with value MimeType is REQUIRED to identify the MIME type of the payload before compression was applied.
• For XML payloads, an eb:PartInfo/eb:PartProperties/eb:Property/@name attribute with value CharacterSet is RECOMMENDED to identify the character set of the payload before compression was applied. The value of this property MUST conform to the values defined in section 4.3.3 of [XML10].

<eb:PartInfo href="cid:a0fe4348-bbde-461b-8edc-070d458a1fc5@example.com">
     <eb:PartProperties>
         <eb:Property name="MimeType">application/xml</eb:Property>
         <eb:Property name="CharacterSet">utf-8</eb:Property>
         <eb:Property name="CompressionType">application/gzip</eb:Property>
     </eb:PartProperties>
</eb:PartInfo> 

Use of compression is configured using the P-Mode parameter PMode[].PayloadService.CompressionType. This parameter is defined as follows in [AS4]:

• If the parameter is present with a value application/gzip: the AS4 Sending MSH SHOULD compress the attached payload(s) over this MEP segment. However, GZIP compression of payloads in data formats that provide native, built-in compression typically does not result in good compression ratios and is therefore NOT REQUIRED.
• If the parameter is absent (default), no compression is used over this MEP segment.

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.

3.3.2. 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 parameter PMode[].Security.SendReceipt.NonRepudiation MUST be set to the value true.
• The parameter PMode[].Security.SendReceipt.ReplyPattern MUST be set to the value Response.

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 parameter PMode[].ReceptionAwareness MUST be set to true.
• The parameter PMode[].ReceptionAwareness.Retry MUST be set to true.
• The parameter PMode[].ReceptionAwareness.DuplicateDetection MUST be set to true.

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.
Reception awareness errors generated by the Sender MUST be reported to the Submitting application:

• The parameter PMode[].ErrorHandling.Report.MissingReceiptNotifyProducer MUST be set to true.
• The parameter PMode[].ErrorHandling.Report.SenderErrorsTo MUST not be set. There is no support for reporting sender errors to a third party.

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.

• If no AS4 Receipt is returned by the Receiving MSH to the Sending MSH for a message, an EBMS:0301, MissingReceipt, Reception Awareness error MUST be generated for the message in the Sending MSH. This error MUST be reported to the Producer, because the parameter PMode[].ErrorHandling.Report.MissingReceiptNotifyProducer is set to true. This obviates the need for both generating and reporting a DeliveryFailure on the Sender side.
• According to the OASIS AS4 specification, if a Receiving MSH cannot successfully complete processing of the message, it MUST NOT return a Receipt. The specification does not define a separate reception awareness error that is the (negative) counterpart to a (positive) AS4 receipt. In this situation, a Receiving eDelivery AS4 MSH SHOULD return the EBMS:0202, DeliveryFailure error to the Sending MSH, which MUST report this error to the Producer.

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.

3.4. 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.

3.4.1. Party Identification

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. The type attribute MUST be used.

For party types registered in ISO 6523:

• The ISO 6523 code MUST used.
• The type SHOULD be set to an ebCore Party ID type format value.

The use of ebCore Party ID MUST follow the profiling specified in the eDelivery ebCore Party Id specification [eDelivery-EBCOREP-v2].

3.4.2. Correlation

AS4 provides multiple mechanisms to correlate messages within a particular flow.

1. eb:UserMessage/eb:MessageInfo/eb:RefToMessageId provides a way to express that a message is a response to a single specific previous message. Presence of an eb:RefToMessageId is required in response messages in Two Way message exchanges. By default, exchanges are considered One Way.
2. eb:UserMessage/eb:CollaborationInfo/eb:ConversationId provides a more general way to associate a message with an ongoing conversation, without requiring a message to be a response to a single specific previous message, but allowing update messages to existing conversations from both Sender and Receiver of the original message.

The ebMS3 and AS4 specifications do not constrain the use of the elements eb:RefToMessageId and eb:ConversationId, but the following profiling applies:

1. eb:UserMessage/eb:MessageInfo/eb:RefToMessageId is to be used to support message exchanges that are modeled as request-response interactions. In the response message, the value of the element MUST be set to the value of the eb:UserMessage/eb:MessageInfo/eb:MessageId element in the request message.
2. eb:UserMessage/eb:CollaborationInfo/eb:ConversationId MUST be included in any AS4 message (as it is a mandatory element). The value MUST be consistent with the data type specified in the ebMS3 XML schema, which is xs:token. In a Two Way exchange, the value of the eb:ConversationId in the response MUST be the same as the value of the eb:ConversationId in the request message.

3.4.3. Test Service

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.

3.4.4. 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.

• The value of eb:Service SHOULD identify a set of related business transactions or other message exchanges in the context of a business process or use case.
• The value of eb:Action SHOULD identify the different types of business transactions or other message exchanges in the context of an identified Service. This MAY be an identifier of a document type, if the exchange of a document of that type unambiguously identifies the purpose and requested action in the context of the Service.

3.4.5. Security

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:

• MUST use static IP addresses (or IP address ranges) for inbound and outbound AS4 HTTPS connections.
• MUST communicate all IP addresses (or IP address ranges) used for outgoing and incoming connections to their trading partners, also covering any passive nodes in active-passive clusters. Note that the IP address of the HTTPS endpoint at which a party accepts incoming pushed AS4 messages may differ from the IP address (or addresses) used by that party for outbound AS4 connections.
• MUST notify their partners about any IP address changes sufficiently in advance to allow firewall and other configuration changes to be applied.

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 specified in section 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 PMode[].Security.X509.Signature.Certificate parameter MUST be set to a value matching the signing certificate of the Sending MSH.
• The PMode[].Security.X509.Encryption.Certificate parameter MUST be set to a value matching the encryption certificate of the Receiving MSH.

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.

3.4.6. 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.

3.4.7. Environments

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.

3.4.8. Networking

This eDelivery AS4 profile MAY be deployed on IPv4 and/or IPv6 networking.

3.4.9. AS4 Usage Rules Profiling

Section 5.1.9 of the OASIS AS4 Specification describes the optional presence of a “filename” value in “Content-disposition” header on MIME body parts to carry file name information. In eDelivery AS4, a Receiving MSH is NOT REQUIRED to provide file name information of message payloads that is encoded using the “Content-disposition” header when delivering AS4 messages.

3.5. P-Mode Parameters

The following table summarizes the P-Mode settings as defined in this eDelivery Common Profile.

4. Profile Enhancements

The eDelivery AS4 Common Profile MAY be enhanced with Profile Enhancements. This section specifies seven such Profile Enhancements. The Profile Enhancements MUST be used in conjunction with the Common Profile. These 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.

Compared to earlier eDelivery versions, this version drops support for the SBDH Profile Enhancement.

4.1. Four Corner Topology

4.1.1. Introduction

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:

• C1 is the original sender party.
• C2 is an Access Point that sends messages on behalf of C1.
• C3 is an Access Point that receives messages on behalf of C4.
• C4 is the final recipient party.

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:

• The C2 is a Receiver and Consumer for the C1-C2 message exchange, and a Producer and Sender for the C2-C3 message exchange.
• The C3 is a Receiver and Consumer for the C2-C3 message exchange, and a Producer and Sender for the C3-C4 message exchange.

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.

4.1.2. Addressing, Party Identification and Tracking Identifier

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/eb:PartyId and eb:To/eb:PartyId 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 topology:

• A property named originalSender MUST be added to the message that identifies the original sender (C1) party.
• A property named finalRecipient MUST be added to the message that identifies the final recipient (C4) party.

As with the eb:From/eb:PartyId and eb:To/eb:PartyId headers, the type attribute MUST 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-EBCOREP-v2].

This profile defines an additional, optional third property:

• A property named trackingIdentifier MAY be added to the message to include an identifier (in arbitrary string format) that allows end-to-end tracking of messages in a four-corner exchange. Its value MAY be set to the value of an identifier for the message from C1 to C2 that the AS4 message relates to. This allows tracking and tracing of messages.

A key advantage of the use of ebMS3 message properties is that no constraints are imposed on the 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:

• Values for the four corner properties MUST be set by the Producer in the submission to the C2 AS4 MSH.
• The use of the four corner properties MUST be consistent with the P-Mode configuration of the C2 AS4 MSH and the C3 AS4 MSH.
• The receiver C3 AS4 MSH MUST include information about these properties and their values in message delivery and MUST use the party identified in the finalRecipient property as C4.

4.1.3. P-Mode Parameters

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.

4.1.4. 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:

• The Message Producer is a separate messaging component that receives messages from an original sender (C1), using a separate messaging infrastructure, and re-submits the message to the C2 Sender AS4 MSH.
• The Message Consumer is a separate messaging component to which the C3 Receiver AS4 MSH delivers the message content and metadata. That Consumer component is responsible for forwarding the message content and metadata to the final recipient (C4), using another separate messaging infrastructure.

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 Topology, 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 Topology 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.

4.1.5. 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].

4.2. Dynamic Receiver

4.2.1. Introduction

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.

4.2.2. 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.

4.2.3. 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:

• One or more Certification Authority root certificates, or certificate path prefixes, that are considered trust anchors for signed messages exchanged under control of the P-Mode.
• Zero or more Certificate Policies that apply to the signing certificate.

For interoperability, efficiency, and to ease validation of the signature by the Receiving MSH, which MAY not have pre-configured the signing leaf certificate, the Sending MSH SHOULD use the X509PKIPathv1 Token Type option defined in section 3.1.2 of [WSSX509]. In this option the wsse:BinarySecurityToken includes an ordered list of X.509 certificates packaged in a PKIPath. Use of this token type MUST be indicated by setting the ValueType attribute on wsse:BinarySecurityToken to the value http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1. The X509v3 Token Type and PKCS7 Token Type defined in sections 3.1.1 and 3.1.3 of [WSSX509] SHOULD NOT be used. A BinarySecurityToken token reference MUST be used to reference the signing token.

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:

• The presented leaf signing certificate MUST chain to one of the specified trust anchors.
• Any policy and issuing Certification Authorities involved in issuing the presented signing certificate MUST implement the specified certificate policies, if any are specified.
  
• Subject identity fields in the presented certificate MUST match the presented values in the eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:From/eb:PartyId structure in the AS4 message. Specific constraints are out of scope for this specification but SHOULD be set by communities using this Profile Enhancement. For example, the Common Name or Organization Identifier field MAY be required to have the same value as the eb:PartyId element.

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.

4.2.4. P-Mode Parameters

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.

4.2.5. 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.

4.2.6. 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.

4.2.7. 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 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.

4.2.8. Limitations

While this Profile Enhancement addresses the requirements of some user communities, it has some important limitations:

• The requirement to adopt a dedicated PKI may not be acceptable for a particular community.
• The initial and ongoing operational costs of a dedicated PKI may be prohibitive.
• Many practical eDelivery scenarios require some ahead-of-time sharing of party identifiers, network security configuration data, IP addresses or address ranges. Whatever secure exchange mechanism is used to pre-share and agree on these parameters could also be used to share certificates, obviating the need for dynamic handling of signing certificates.
• The approach is not compatible with the Pull Profile Enhancement, as it assumes that a Receiving MSH is always a Responding MSH.
• The license structure of commercial messaging software is very often linked to the number of partners a customer wants to exchange messages with, with higher license fees for larger (or unlimited) numbers of partners. In this Profile Enhancement, the number of communication partners is not known.

4.3. Dynamic Sender

4.3.1. Introduction

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:

• When used in combination with the Four Corner Topology Profile Enhancement, in a One Way exchange the PMode.Responder.Party (which corresponds to the C3) is not known but the finalRecipient ebMS3 Property (which corresponds to the C4) is provided by the Producer. In this case, the PMode.Responder.Party is determined dynamically, in addition to the Receiver MSH specific AS4 protocol parameters.
• When used for Point-to-Point communication, in a One Way exchange the PMode.Responder.Party is set directly by the Producer. Additional Receiver specific AS4 protocol parameters are determined dynamically for this party.
  

Note that a conformant deployed MSH MAY be a Dynamic Sender for some services and not for others.

4.3.2. 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.

• One or more P-Mode templates MUST be deployed in the AS4 MSH for Dynamic Sender use that have preset values for the PMode.Initiator.Party, PMode.Initiator.Role, PMode.Responder.Role, PMode[].BusinessInfo.Service and/or PMode[].BusinessInfo.Action parameters. These templates MUST NOT have values for PMode.Responder.Party, PMode[].Security.X509.Encryption.Certificate, and PMode[].Protocol.Address. The PMode[].Security.X509.Encryption.Certificate and PMode[][s].Security.X509.Signature.Certificate MAY be used to specify constraints on trust anchors or certificate policies but MUST NOT specify any specific leaf certificate.
• If a message is submitted and matched to a P-Mode template that uses the Dynamic Sender Profile Enhancement, a request is issued to the discovery infrastructure to obtain additional information to fully instantiate the P-Mode. This request takes as input parameters:
  • The parameters specified in the P-Mode template. (This is needed because different configurations MAY be discovered depending on the supplied values, for example for different services or actions.)
  • If the P-Mode template relates to a point-to-point AS4 exchange, the expected PMode.Responder.Party value.
  • If the P-Mode template relates to a Four Corner Topology configuration, Party identification for the finalRecipient. This will be used as value for the finalRecipient ebMS3 Property and, in addition, will be used to determine the PMode.Responder.Party.
• When used in combination with the Common Profile, the discovery infrastructure should limit results to P-Modes that used the signing and key exchange algorithms specified in section 3.6 and set the PMode[].Security.X509.Signature.Algorithm parameter accordingly..
• When used in combination with the optional enhancement for support for alternative curves and algorithms defined in section 4.8 below, it should limit results to either values specified in the Common Profile or values specified in that section and set the PMode[].Security.X509.Signature.Algorithm parameter accordingly.
• A successful response from the discovery infrastructure has matching values for the input parameters, and provides values for additional parameters and leaf certificates for the Receiver.
• If the discovery infrastructure successfully returns:
  • The Submit operation succeeds.
  • The P-Mode MUST be deployed in the AS4 MSH and the submitted AS4 message MUST be sent using this P-Mode.
  • The deployed P-Mode MUST be used to process receipt or error signals from the Responder MSH.
    
• If the request to the discovery infrastructure is unsuccessful:
  • The Submit operation fails.
    

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.

4.3.3. 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.

4.3.4. 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:

• includes a eb:RefToMessageId set to the eb:MessageId of the first leg request message;
• reverses the eb:From and eb:To party identifiers and roles;
• sets the eb:Service and eb:Action for the response;
• in a Four Corner Exchange, reverses the eb:originalSender and eb:finalRecipient parameters.

The discovery infrastructure is used to determine the PMode[2].Protocol.Address, PMode[2].Security.X509.Encryption.Certificate and PMode[2][s].Security.X509.Signature.Certificate parameters.

4.3.5. 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.

4.3.6. 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.

4.3.7. Limitations

While this Profile Enhancement addresses the requirements of some user communities, it has some important limitations:

• Many practical eDelivery scenarios require some ahead-of-time sharing of party identifiers, network security configuration data, IP addresses or address ranges. Whatever secure exchange mechanism is used to pre-share and agree on these parameters could also be used to share ahead-of-time the parameters that the Dynamic Sender enhancement provides just-in-time.
• The approach is not compatible with the Pull Profile Enhancement, as it assumes that a Sending MSH is always an Initiating MSH.
• The license structure of commercial messaging software is very often linked to the number of partners a customer wants to exchange messages with, with higher license fees for larger (or unlimited) numbers of partners. In this Profile Enhancement, the number of communication partners is not known.

4.4. Pull Feature

4.4.1. Introduction

The eDelivery AS4 Common Profile mandates support for the “Push” ebMS3 MEP Transport Channel Binding, as it is sufficient for and covers the requirements of the vast majority of its users. This eDelivery AS4 Pull Feature Profile Enhancement specifies an optional alternative use of the “Pull” Transport Channel Binding. Selection of Push or Pull is configured in the P-Mode for the message exchange.

4.4.2. Rationale for Pull

Reasons to deploy the Pull Transport Channel Binding may include the following:

• A Receiver does not have a fixed IP address and/or DNS-resolvable server address.
• A Receiver does not allow incoming TCP/IP connections. This is preferred by some organizations for reasons of security policy or to simplify network management. 
• A Receiver is not guaranteed to be available 24/7. This is sometimes the case with smaller organizations, or organizations with smaller IT budgets.

The Pull feature also has some important drawbacks:

• There is an unavoidable, variable delay between the point in time at which the message is produced and submitted to the Responding MSH of the Sender and the point in time at which it is pulled by the Initiating MSH of the Receiver. This delay may be problematic or even unacceptable for time-critical exchanges, in which there may be legal or contractual obligations to deliver data in a timely manner.
• The Receiver is (typically) unaware if/when messages are available, and therefore has to issue Pull requests to check if any messages are available, even if there are no messages on the Sender side. The overhead is particularly high for Senders that have many low-volume communication partners.

4.4.3. Message Exchange Patterns

When using Pull, the transfer of a user message is initiated by the Receiver, which connects, as an HTTPS client, to the Sender. The Sender operates an HTTPS server that accepts Pull requests over HTTPS and returns the user message on the HTTPS backchannel. The Pull binding reverses the pattern of the Push binding, in which the Sender of the message initiates the transfer, as an HTTPS client, to the responding Recipient, which operates an HTTPS server.

The eDelivery AS4 Pull feature can be used with both One Way and Two Way MEPs. The eDelivery AS4 Pull Profile Enhancement REQUIRES support for the following Transport Channel Bindings:

• One Way Pull
• Two Way Push-and-Pull
• Two Way Pull-and-Push

These three bindings complement the two bindings supported by the eDelivery AS4 Common Profile, viz. One Way Push and Two Way Push-and-Push.

An implementation that supports the eDelivery AS4 Pull Profile Enhancement in addition to the eDelivery AS4 Common Profile MUST allow the selection of one of the two supported bindings for a One Way exchange, and of one of the three supported bindings for a Two Way exchange. The selection MUST be made using P-Mode parameter settings for each individual P-Mode and MUST be agreed in deployment configurations between Sender and Receiver Party.

If the PMode.MEPBinding parameter in the P-Mode that controls the exchange of a message that is submitted specifies that the message is to be pulled, then the MSH will act as Responding Sender to Pull requests that target the message partition channel specified in its PMode[].BusinessInfo.MPC parameter. For this P-Mode, the Initiating Receiver MUST post Pull requests to the Sending MSH.

In the eDelivery AS4 Common Profile, receipts and errors are exchanged synchronously, using the backchannel of the HTTPS connection on which the related user message was transferred. With Pull, the backchannel is used to carry the AS4 user message. Therefore, when using Pull, signals on pulled user messages MUST be transmitted asynchronously, using an HTTPS POST from the Receiver to the Sender MSH.

In ebMS3, the URL to which signals on pulled user messages are to be posted is configured using the PMode[].ErrorHandling.Report.ReceiverErrorsTo parameter (for errors) and the PMode[].Security.SendReceipt.ReplyTo parameter (for receipts). To simplify implementation and deployment, these URLs MUST be set to the same value as the URL from which the user message was pulled. Conformant implementations MUST support processing all signal messages related to an MPC posted to a single URL. 

4.4.4. Reliability for Pulled Messages

The profiling of AS4 Reception Awareness in the eDelivery AS4 Common Profile also applies to exchanges using this eDelivery AS4 Profile Enhancement. This Profile Enhancement describes how this feature is to be used in combination with Pull channel bindings in eDelivery AS4.

One of the capabilities of Reception Awareness is Message Retry. The PMode[].ReceptionAwareness.Retry.Parameters parameter controls Message Retry for a P-Mode leg. AS4 does not define these retry parameters in detail, but indicates that they control the number of retries and the retry interval.

In a deployed MSH, acting as Sending MSH, multiple messages intended to be transferred to a Receiving MSH in response to Pull requests targeting the MPC specified in the P-Mode may be submitted over time. This message set is ordered temporally using the eb:Timestamp value. As timestamps are generated in the Sending MSH when the message is submitted, this order also reflects the order of submission.

At any point in time, for each MPC, zero, one or more messages, made available for pulling on that MPC to an MSH, may be available for the MPC in each of the following states:

1. Messages that have not yet been pulled at all.
2. Messages that have been pulled at least once, or are in the process of being pulled, for which no valid eb:Receipt or eb:Error signal has been returned and for which the duration since the last pull is longer than the Reception Awareness retry interval.
3. Messages that are like the messages in state (2), except that in their case the duration of the interval since the last pull is shorter than the Reception Awareness retry interval.
4. Message that have been pulled and for which either a valid eb:Receipt or eb:Error signal has been returned.
5. Message for which no receipt or error was returned in time.

In response to successfully authorized Pull requests, the Responding Sending MSH SHOULD return the oldest message (based on submission eb:Timestamp) in either the first or the second of these states, if available. After this, the pulled message is in state (3).

Receivers are expected to acknowledge positive reception of pulled user messages using ebMS3 eb:Receipt signal messages and to report errors using eb:Error signal messages. For a message in state (3), the Initiating Receiving MSH is given time to acknowledge the message using a receipt or error until its Retry interval expires.

• If the acknowledgment signal is returned in time to the Sending MSH, the message is in the final state (4) and has been processed completely.
• If the Receiving MSH fails to return such a signal in time (possibly because of some network or processing error), on the Sending MSH side, then the Sending MSH MUST:
  • If the maximum number of retries has not yet been reached, change the message state to state (2), causing the message to be available again for pulling. The MSH MAY do this automatically, or allow some (manual or other) application control.
  • If the maximum number of retries has been reached, change the message state to state (5).

Note that in situations where there are processing or networking errors that trigger retries, the order in which pulled messages are received and delivered does not necessarily reflect the order in which they were submitted to the sending MSH. This is the same as for pushed messages.

Also note that, because messages that have been pulled recently, or still are in the process of being pulled, are in state (3), multiple Pull requests can be made in parallel to the Sending MSH for the same MPC, each of which will pull different user messages (if available), or an EBMS:0006, EmptyMessagePartitionChannel error.

Messages in states (4) and (5) are in final state and are not, and will never again be, available for pulling. Once reaching state (5), the message is considered failed and an EBMS:0301, MissingReceipt is to be generated at the Sending MSH side. Reporting of this error to the producer is controlled using the parameter PMode[].ErrorHandling.Report.ProcessErrorNotifyProducer.

On the Receiver side, the REQUIRED use of Duplicate Detection means that Receivers MUST detect any duplicate pulled messages, in the same way as they do for pushed messages.

The ebMS3 and AS4 specifications do not define configuration parameters or strategies that control when Pull requests are issued. Some considerations (not precluding others) affecting timing of Pull requests include:

• If an MPC is not empty, a Pull request returns a user message, but other user messages may be available. The Initiating MSH can only check for such additional user messages by posting another Pull request for the MPC.
• The Receiving MSH MUST pull sufficiently often to prevent submitted messages from timing out and from causing EBMS:0301, MissingReceipt errors to be generated on the Sending MSH side.
• Parties SHOULD agree on a balance between pulling sufficiently often for timely transfer of messages, and leaving sufficient time in between Pulls to keep network and processing load to acceptable levels.
• In Push-and-Pull Two Way exchanges, the timing of the Pull MAY be set to match the expected processing time, i.e. the Pull could be scheduled at a point in time at which the business response user message is expected to be available.
• In some situations, availability of messages may follow known patterns (e.g. some flows may only happen during office hours), which could be taken into account.

Note that interoperability is not affected by selection of strategies for timing Pull requests.

4.4.5. MPC Authorization

In eDelivery AS4, authorization of the Pull feature MUST use the second authorization option described in the Security section in section 2.1.1 of the AS4 standard [AS4]. In this option, a regular WS-Security security header using an XML Signature using an X.509 certificate is used to secure the Pull request signal message and there is no additional WS-Security security header targeted to “ebms”. The Sending MSH MUST use the credential present in this security header for Pull authorization, i.e. to authorize the Pull request to access messages on a specific MPC.

This eDelivery AS4 Pull Profile Enhancement constrains authorization to be at MPC level rather than at P-Mode level. P-Mode configurations MUST be constrained such that, if a Responding Receiving MSH and the party it provides messaging services for are authorized to pull messages for a particular P-Mode within a particular MPC, it is authorized to pull all messages on that MPC. For background and discussion, see https://issues.oasis-open.org/browse/EBXMLMSG-20.

Pull Requests MUST be signed using the signing certificate of the Receiver Party.

By convention, the default MPC http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC MUST NOT be used for Pull exchanges. Each MPC used for pulling MUST be associated with at most one Receiver Party. This allows the Responding MSH to determine, for each MPC, which certificate MUST be used to sign Pull requests targeting that MPC.

4.4.6. P-Mode Parameters

The following table summarizes the P-Mode parameters related to the eDelivery AS4 Pull Profile Enhancement:

4.5. Large Message Splitting and Joining

4.5.1. Introduction

Available implementations of the eDelivery AS4 Common Profile have demonstrated an ability to exchange AS4 messages up to 2 GB in size. This covers the requirements of the vast majority of eDelivery AS4 users. However, some users of eDelivery have expressed a need to exchange very large messages (potentially up to hundreds of gigabytes). This eDelivery AS4 Profile Enhancement specifies an optional alternative mechanism for exchanging such very large messages that is based on the ebMS3 Part 2 “Large Message Splitting and Joining” feature [EBMS3P2], profiled and adjusted for use with eDelivery AS4. Note that corrections to this feature relevant to this Profile Enhancement exist [EBERRATA].

4.5.2. Feature Overview

The “Large Message Splitting and Joining” feature for MIME-based SOAP messaging is specified in section 4 of the ebMS3 Part 2 specification [EBMS3P2]. It provides a mechanism for allowing a Sending MSH to split a large MIME-enveloped SOAP message, referred to as the source message, into a set of smaller MIME-enveloped SOAP messages, referred to as fragment messages, which MUST be joined at the Receiving MSH side. The resulting target message is an identical copy of the source message. The feature also supports compression.

To indicate that a SOAP message is a fragment message, a mf:MessageFragment SOAP header MUST be included in the SOAP message. Presence of this header indicates that a SOAP message carries part of the content of an underlying larger source message. It has a sub-element mf:GroupId to identify the group of fragments it is part of, an element mf:FragmentNum to indicate the sequence number within that group and an element mf:FragmentCount that states the number of fragments into which the message has been split. The specification provides an XML schema for the mf:MessageFragment header and specifies the behavior of the SOAP message Sender and Receiver.

A mf:MessageFragment header MUST be understood, i.e. it MUST have its S12:mustUnderstand attribute set to a true value.

As eDelivery AS4 is based on SOAP 1.2, the Content-Type of the MIME part containing the SOAP envelope in both source and fragment messages and the mf:Type element in mf:MessageHeader MUST have the value application/soap+xml.

The Split and Join feature is transparent to Producer and Consumer. The Submit and Deliver MSH operations are atomic and relate to source messages, irrespective of size. Delivery of the source message does not occur until all fragment messages in a fragment group are received and the source message is successfully re-assembled by the Receiver MSH from the fragment messages. Note that this does not preclude implementations from providing interfaces to allow Producer and/or Consumer to monitor in-progress transmissions.

Splitting and Joining is a general feature for SOAP-based Web Services. Section 4.4.2 of the ebMS3 Part 2 specification provides details on the use of Split and Join specifically with ebMS3. It specifies the format of a SOAP message fragment for an ebMS3 message, the required use of an eb:Messaging header on the fragment message derived from the corresponding header on the source message, and the application of security and other ebMS3 messaging features to source message and/or fragment messages.

With ebMS3, the splitting, (de)compression and joining operations are applied by the Sending and Receiving MSH subject to P-Mode configuration. Splitting is only allowed for legs in P-Modes for which PMode[].Splitting is set. A single P-Mode may be used for small and large messages. Setting the parameter indicates the MSH MAY use Splitting and Joining, but this is NOT REQUIRED. The parameter indicates that the Receiving MSH MUST perform Joining of message fragments, if Splitting was used by the Sending MSH. There are no inherent limitations in the protocol on the maximum size of the source message or on the number of payloads in the source message or on their relative sizes.

4.5.3. Message Exchange Patterns

Splitting and Joining is compatible with One Way and Two Way Message Exchange Patterns. Subject to P-Mode configuration, it can be applied on a per-leg basis, meaning that in a Two Way MEP, it may be applied to the first and/or the second leg, or to none of them.

Splitting and Joining is also compatible with both use of a Push transport channel (used in the eDelivery Common Profile) and of a Pull transport channel (used in the eDelivery Pull Profile Enhancement).

4.5.4. Error Handling

For messaging involving Split and Join, errors MAY be generated for message fragments and for the source message. For the source message, error reporting MUST be done asynchronously. For fragment messages, error reporting MUST be done synchronously, as in the Common Profile.

The P-Mode parameters for error handling that MUST be applied to eDelivery AS4 messages are specified in the eDelivery Common Profile, with the following exceptions:

• The parameter PMode[][source].ErrorHandling.Report.AsResponse MUST be set to a false value for legs that may use Split and Join.
• The parameter PMode[][source].ErrorHandling.Report.ReceiverErrorsTo MUST be set to the URL to be used for asynchronous error signal messages. To simplify implementation and deployment, this URL MUST be set to the same value as the URL at which the MSH receives inbound user messages.

For the use of the [source] label, see https://issues.oasis-open.org/browse/EBXMLMSG-117.

An overview of errors specific to the Split and Join feature is provided in section 4.6 of ebMS3 Part 2 [EBMS3P2]. These concern situations in which individual fragments are successfully processed, but errors occur in processing related to the Splitting and Joining feature.

4.5.5. Security

As specified in section 4.4.2 of ebMS3 Part 2 [EBMS3P2], WS-Security processing MUST be applied to message fragments rather than to the source message. The P-Mode parameters for message security that MUST be applied to eDelivery AS4 messages are specified in the eDelivery Common Profile. This means that result fragment messages MUST be signed and encrypted. The source message itself is neither signed nor encrypted. Non-Repudiation of Origin is established as follows:

• Fragments are signed individually. The signature commits the Sender to the content of the fragment message. Collectively, the fragment messages sign the entire source message content.
• Fragments are individually numbered and the number of fragments a source message is split into is communicated to the Receiver. It is not possible to alter the source message content by re-ordering, adding or omitting fragments without detection.

Sections 5.1.4 and 5.1.5 of the AS4 specification [AS4] express which parts of an AS4 message MUST be covered in the signature for the message when XML Signature is applied to an AS4 message. In addition to these, the mf:MessageFragment MUST be signed. The MIME part referenced by the @href attribute on mf:MessageFragment MUST be signed.

Sections 5.1.6 and 5.1.7 of the AS4 specification [AS4] express which parts of an AS4 message MUST be encrypted when XML Encryption is applied to an AS4 message. The mf:MessageFragment MUST NOT be encrypted. The MIME part referenced by the @href attribute on mf:MessageFragment MUST be encrypted.

4.5.6. Reliable Messaging and Non-Repudiation of Receipt

At the time of its writing, the ebMS3 Part 2 “Large Message Splitting and Joining” module [EBMS3P2] assumed messaging reliability for ebMS3 messages would be provided by the Reliable Messaging Module defined in section 8 of the ebMS3 Core Specification [EBMS3]. That module is based on Web Services reliable messaging protocols such as Web Services Reliable Messaging (WS-RM). This protocol has not gained traction in the marketplace and is not used in AS4.

This Profile Enhancement therefore instead uses the Reception Awareness and Duplication Detection feature defined in section 3.2 of the OASIS AS4 profile [AS4]. Where WS-RM uses a sequence acknowledgment mechanism, AS4 receipts are per-message receipts. For messaging using the Split and Join feature that are successfully processed (as described in [AS4], section 3.4):

• Receipts MUST be generated for message fragments and returned synchronously to prevent unnecessary Message Retry. This is a deviation from ebMS3 Part 2, in which Receipts were only used for the source message receipt and reliability of message fragments is provided by Web Service Reliable Messaging.
• A Receipt MUST also be generated and returned for the source message. A Receipt for a source message indicates that all related fragment messages have been successfully processed and joined to form the source message successfully.
• The total number of receipts expected for a message to which Splitting and Joining has been applied is therefore 1 + the value of mf:FragmentCount.
• For the source message, receipt reporting MUST be done asynchronously. This means that:
  • The parameter PMode[][source].Security.SendReceipt.ReplyPattern MUST be set to the value callback.
  • The parameter PMode[][source].Security.SendReceipt.ReplyTo MUST be set to the URL to be used for asynchronous receipt signal messages. To simplify implementation and deployment, this URL MUST be set to the same value as the URL at which the MSH receives inbound user messages.
  • For fragment messages, receipt reporting follows the Common Profile.
  • AS4 Message Retry MUST be applied to message fragments. It MUST NOT be applied to the source message.
  • AS4 Duplicate Elimination MUST be applied to both message fragments and to the source message.
  • All other P-Mode parameter values for receipt handling set in the eDelivery AS4 Common Profile apply.

For the use of the [source] label, see https://issues.oasis-open.org/browse/EBXMLMSG-117.

The format of the AS4 Receipt MUST follow the Profiling Rules specified in section 5.1.8 of the AS4 specification [AS4]:

• For AS4 fragment messages, the Receipt MUST be a Non-Repudiation Receipt following Profiling Rule (b). Collectively, the ds:Reference and ds:DigestValue elements in these receipts, which can be taken from the ds:Signature elements in the received fragment messages, commit the Receiver to the entire source message content.
• For the AS4 source message, the Receipt MUST be a Reception Awareness Receipt following Profiling Rule (a). This is an adjustment for AS4 from ebMS3 Part 2, which specifies in section 4.4.2 (in the paragraph starting with the sentence “To generate a receipt acknowledgment for non-repudiation”) the use of Non-Repudiation Receipts for the source message. Since this profile uses message fragment level Non-Repudiation Receipts, it obviates the need for XML Signature processing at the source message level and so simplifies implementations by using Reception Awareness Receipts instead of Non-Repudiation Receipts for the source message.

4.5.7. Compression

In Splitting and Joining, compression of a source message is done by the Sending MSH after submission, before Splitting. This generally results in a better compression ratio than if compression were to be applied separately to fragments after Splitting. Decompression is done after all the fragments have been joined, but before message delivery. In eDelivery, the following P-Mode parameter settings MUST be used:

• The PMode[].Splitting.Compression parameter MUST be set to a true value.
• The PMode[].Splitting.Compression.Algorithm parameter MUST be set to the value “gzip”. This is the IANA content code [IANACC] for the GZIP Compressed Data Format [RFC1952].

As a clarification to ebMS3 Part2, implementations MAY not apply compression even if the PMode[].Splitting.Compression parameter is set to a true value, as in AS4. This is useful for situations in which the source message content mostly consists of binary data payloads in natively compressed formats. Therefore, compression either:

• Has been applied to the source message. In this case, a fragment message for the related mf:GroupId MUST include a mf:MessageFragment element that MUST include a mf:CompressionAlgorithm element with value “gzip”.
• Has not been applied to the source message. In this case, in all of the related fragment messages the mf:MessageFragment MUST NOT contain a mf:CompressionAlgorithm element.

When Splitting and Joining is applied, AS4 Compression of payloads MUST NOT be applied to either fragment messages or the source message.

4.5.8. Relation to other Profile Enhancements

This Profile Enhancement can be used in conjunction with other eDelivery AS4 Profile Enhancements.

• When used in combination with the Four Corner Profile Enhancement, the message properties originalSender, finalRecipient and trackingIdentifier MUST be listed in the PMode[].Splitting.RoutingProperties parameter. As a result, they MUST be included with each result fragment message. This supports some routing scenarios.
• The Profile Enhancement can also be used with the Dynamic Receiver Profile Enhancement and the Dynamic Sender Profile Enhancement.
• This Profile Enhancement can be used with either Push or Pull transport channel binding. It is therefore compatible with the eDelivery AS4 Pull Profile Enhancement.

When the eDelivery Dynamic Sender Profile Enhancement is used and eDelivery SMP is used as discovery infrastructure protocol, the bdxr-transport-ebms3-as4-split-join-v2p0-curve25519 or bdxr-transport-ebms3-as4-split-join-v2p0-ecdsa transport profile identifiers MUST be used instead of the bdxr-transport-ebms3-as4-v2p0-curve25519 or bdxr-transport-ebms3-as4-v2p0-ecdsa identifiers. This indicates a Receiver’s capability to receive eDelivery AS4 messages using this eDelivery Split and Join Profile Enhancement.

4.5.9. P-Mode Parameters

The following table summarizes the P-Mode parameters related to the eDelivery Large Message Splitting and Joining Profile Enhancement:

4.6. ebCore Agreement Update

4.6.1. Introduction

The OASIS ebCore Agreement Update specification [ebcore-au-v1.0] provides a mechanism to securely update an existing AS4 messaging configuration. It provides an extensible base protocol and message format and a specific predefined protocol for certificate updates. This eDelivery Profile Enhancement uses an extended subset of the OASIS specification to securely update:

• long-lived signing certificates.
• long-lived encryption certificates.
• short-lived encryption certificates.

Optionally, as an extension, it also supports secure updates of:

• Endpoint address URLs.
• Messaging profiles or profile versions.
• Security algorithms and related parameters.
• Network security (whitelisting) address updates. 

4.6.2. Profiling of ebCore Certificate Update

To use the ebCore Certificate Update part of ebCore Agreement Update [ebcore-au-v1.0] according to this AS4 profile, the AS4 MSH:

• MUST be able to exchange ebCore Certificate Update AS4 messages. As AS4 is payload-agnostic, this imposes no special requirements on products. The only requirement on implementers deploying AS4 products is that these messages MUST use the predefined Service and Action values in the OASIS specification.
• MUST provide functionality to create an ebCore Certificate Update document; use it to submit an update to an AS4 configuration; convert the success/failure of such an update to a positive/negative ebCore response document; provide an interface to the AS4 MSH for submission and delivery of ebCore documents exchanged with communication partners.
• MUST sign ebCore Certificate Update messages as any AS4 message conformant to the profile.

The ebCore Certificate Update protocol can be used in conjunction with this profile for two purposes:

• As a mechanism to update a long-lived certificate containing a public key that is used, among others, for signing. In this case, the certificate is required to be issued by a Certification Authority and the update frequency is low (typically once every few years or months).
• As a mechanism to update a certificate containing a public key of a party that is only used for key agreement to support encryption. In this case, the certificate may be issued by the party rather than by a Certification Authority. As it is exchanged in an ebCore Certificate Update message, the integrity and authenticity of the public key are protected.

In addition to supporting updating the certificate used for AS4 message signing, ebCore Certificate Update MAY be used to update the static key of the recipient used in the ephemeral-static key exchange. In ideal cryptographic protocols, ephemeral keys are only used once for establishing symmetric keys. It is RECOMMENDED to changing ephemeral keys as frequently as possible, giving potential attackers less chance to break previous messages. Therefore, it is RECOMMENDED to use ebCore Certificate Update to update keys such that keys are replaced within 7 days. The 7 day limit is the maximum lifetime TLS 1.3 [RFC8446] uses for session tickets which effectively break forward secrecy of TLS connections.

Automatic processing of ebCore Certificate Update messages (i.e. processing of update requests not requiring intervention by a human operator or non-immediate service management process) allows low-overhead, frequent updates of the static key contained in the certificate for the recipient for key exchange. The static key in practice approximates an ephemeral key.

While ebCore Certificate Update packages keys using certificates, the certificates containing ECDH public keys do not need to be signed by a certification authority. As they are issued using signed ebCore Agreement Update messages, their authenticity is established.

4.6.3. Endpoint Update

In addition to using the generic Certificate Update functionality, implementations MAY provide more general update functionality using the extensibility feature of ebCore Agreement Update. This functionality includes secure updates of:

• Endpoint address URLs.
• Messaging profiles or profile versions.
• Security algorithms and related parameters.
• Network security (whitelisting) address updates.

To implement Endpoint Update, implementations MUST support the ebCore Agreement Update as extended to Endpoint Update in the submission to the OASIS ebCore TC, [ebcore-ep-draft-2023-02].

4.7. Alternative Elliptic Curve Cryptography Option

In order to provide a fall-back for the (highly unlikely) situation in which vulnerabilities are found in the algorithms for signing (based on Ed25519) or encryption (based on X25519), or to be able to have a choice of issuing PKI Certification Authorities, AS4 products supporting this profile enhancement MAY also support signing and encryption based on alternative Elliptic Curve Cryptography.

4.7.1. Signature using ECDSA

This profile enhancement differs from the Common Profile such that for signature:

• The signature algorithm is set to http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256.

This profile enhancement differs from the [BDEW AS4] profile as follows:

• The key derivation function is http://www.w3.org/2021/04/xmldsig-more#hkdf as in the Common Profile.

4.7.2. Encryption using ECDH-ES

This profile enhancement differs from the Common Profile such that for encryption:

• The key agreement algorithm used is http://www.w3.org/2009/xmlenc11#ECDH-ES.
• The originator key is encoded as an dsig11:ECKeyValue element instead of a dsig11:DEREncodedKeyValue element as in the Common Profile.

This profile enhancement differs from the [BDEW AS4] profile as follows:

• The key derivation function is http://www.w3.org/2021/04/xmldsig-more#hkdf as in the Common Profile.
• It is not restricted to Brainpool curves.

Implementations MUST support at least the secp256r1, secp384r1, secp521r1, BrainpoolP256r1 curves but MAY also support other ECC curves. The URI attribute on dsig11:NamedCurve is to be set to a URN that uses the elliptic curve object identifier for the named curve as follows:

• For BrainpoolP256r1, the OID is 1.3.36.3.3.2.8.1.1.7. The value to use for the URI attribute on dsig11:NamedCurve is therefore urn:oid:1.3.36.3.3.2.8.1.1.7.
• For secp256r1 the attribute value is urn:oid:1.2.840.10045.3.1.7.
• For secp384r1 the attribute value is urn:oid:1.3.132.0.34.
• For secp521r1 the attribute value is urn:oid1.3.132.0.35.
• For other curves, the attribute value is to be set analogously based on its OID.

The following XML snippet shows an xenc:AgreementMethod based on ECDH-ES instead of X25519.

<?xml version="1.0" encoding="UTF-8"?>
<xenc:AgreementMethod Algorithm="http://www.w3.org/2009/xmlenc11#ECDH-ES" 
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:dsig-more="http://www.w3.org/2021/04/xmldsig-more#"
    xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <xenc11:KeyDerivationMethod
        Algorithm="http://www.w3.org/2021/04/xmldsig-more#hkdf"
        xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
        <dsig-more:HKDFParams
            xmlns:dsig-more="http://www.w3.org/2021/04/xmldsig-more#">
            <dsig-more:PRF
                Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
            <dsig-more:Salt>DXitIRbhMjQaOT3WXgi8Nj1iNaiy5UPCpdjwXwun8Mk=</dsig-more:Salt>
            <dsig-more:Info>dGVzdC1pbmZvLWRhdGE=</dsig-more:Info>
            <dsig-more:KeyLength>16</dsig-more:KeyLength>
        </dsig-more:HKDFParams>
    </xenc11:KeyDerivationMethod>
    <xenc:OriginatorKeyInfo>
        <ds:KeyValue>
            <dsig11:ECKeyValue xmlns:dsig11="http://www.w3.org/2009/xmldsig11#">
                <dsig11:NamedCurve URI="urn:oid:1.3.36.3.3.2.8.1.1.7"/>
                <dsig11:PublicKey>
                    BAHQXIjLoPO4LBehXFzOveAzouszXfs3aTmkFiwPrsXwTgaV7lBy5B7mPRLYCB7NgPlWD/Yhx1Oq
                    JmSkrU+HjugU6AFPPrUmNARHk7x+JKK+V5v8ErNO1+GSnB25X6N9y08rIHeYaazT5Rc9YpdwEFBG
                    mPOciWlDJCOfRVLJtcRF2X6L0Q== 
                </dsig11:PublicKey>
            </dsig11:ECKeyValue>
        </ds:KeyValue>
    </xenc:OriginatorKeyInfo>
    <xenc:RecipientKeyInfo>
        <ds:KeyValue>
            <!-- Assumes the recipient key is/has been shared as a certificate and can be 
                        referenced using its SKI. -->
            <wsse:SecurityTokenReference>
                <wsse:KeyIdentifier
                    EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"
                    > ENCODED </wsse:KeyIdentifier>
            </wsse:SecurityTokenReference>
        </ds:KeyValue>
    </xenc:RecipientKeyInfo>
</xenc:AgreementMethod>

5. Example

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 Topology Profile Enhancement.

In the example, both the C1 original sender, the C4 final recipient and intermediate C2 and C3 parties identified are using GS1 GLN numbers encoded as ebCore Party Identifiers.

The security header is omitted from this example. An example of a security header is included in section 3.4 above.

Content-Type: multipart/related; type="application/soap+xml"; 
      boundary="b6e68776-47ea2784152c-de60-4b15-b324-b399052af5f1"; 
      start="<a397-ca2a711dff5b@seller.eu>"; start-info="application/soap+xml"
Content-Length:7308

--b6e68776-47ea2784152c-de60-4b15-b324-b399052af5f1
Content-Type: application/soap+xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-ID: <a397-ca2a711dff5b@seller.eu>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Header>
        <eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
            env:mustUnderstand="true" wsu:Id="_210bca51-e9b3-4ee1-81e7-226949ab6ff6">
            <eb:UserMessage
                mpc="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC">
                <eb:MessageInfo>
                    <eb:Timestamp>2017-10-24T09:07:36.000Z</eb:Timestamp>
                    <eb:MessageId>8196c8e2-820f-4aec-a1ca-288a4d1d4020@seller.eu</eb:MessageId>
                </eb:MessageInfo>
                <eb:PartyInfo>
                    <eb:From>
                        <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"
                            >1234567890</eb:PartyId>
                        <eb:Role>Seller</eb:Role>
                    </eb:From>
                    <eb:To>
                        <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"
                            >0987654321</eb:PartyId>
                        <eb:Role>Buyer</eb:Role>
                    </eb:To>
                </eb:PartyInfo>
                <eb:CollaborationInfo>
                    <eb:Service>http://esens.eu/services/eprocurement/1.0</eb:Service>
                    <eb:Action>ConfirmOrder</eb:Action>
                    <eb:ConversationId>E5D7CFEE-E6A9-4855-A67E-6C24403E35E6</eb:ConversationId>
                </eb:CollaborationInfo>
                <eb:MessageProperties>
                    <eb:Property name="originalSender"
                        type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"
                        >5209999001264</eb:Property>
                    <eb:Property name="finalRecipient"
                        type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"
                        >5209999001295</eb:Property>
                </eb:MessageProperties>
                <eb:PayloadInfo>
                    <eb:PartInfo href="cid:1400668830234@seller.eu">
                        <eb:PartProperties>
                            <eb:Property name="MimeType">text/xml</eb:Property>
                            <eb:Property name="CompressionType">application/gzip</eb:Property>
                        </eb:PartProperties>
                    </eb:PartInfo>
                </eb:PayloadInfo>
            </eb:UserMessage>
        </eb:Messaging>
        <wsse:Security
            xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
            env:mustUnderstand="true">
            <!-- OMITTED,  see above -->
        </wsse:Security>
    </env:Header>
    <env:Body
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        wsu:Id="_840b593a-a40f-40d8-a8fd-89591478e5df"/>
</env:Envelope>


--b6e68776-47ea2784152c-de60-4b15-b324-b399052af5f1
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <1400668830234@seller.eu>

âǕœÙ
„oFðGÌ|ҖNÑ	ÜóB:á“&’›¾l»À‘™TܟõŠ’4¥™tFd³L
--b6e68776-47ea2784152c-de60-4b15-b324-b399052af5f1--

6. Conformance

This section defines ten Conformance Clauses. In this version, the eDelivery AS4 SBDH Conformance Clause provided in earlier versions of eDelivery AS4 has been dropped.

6.1. 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:

• Support the extended subset of the feature of the AS4 ebHandler Profile specified in section 3.2.
• Support the AS4 Additional Features Payload Compression and Reception Awareness and Duplicate Elimination, as specified in section 3.3.
• Support the Usage Rules defined in section 5.1 of [AS4] and as profiled as profiled in section 3.4., and the Common Usage Profile in section 3.5.
• Support the P-Mode parameters as specified in section 3.5.
• Support the WS-I conformance requirements as specified in section 2.1 of [AS4].

This Conformance Clause is adapted from the AS4 ebHandler Conformance Clause, specified in section 6.1 of [AS4].

6.2. eDelivery AS4 Four Corner Topology Conformance Clause

In order to conform to the eDelivery AS4 Four Corner Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.1.

6.3. eDelivery AS4 Dynamic Receiver Conformance Clause

In order to conform to the eDelivery AS4 Dynamic Receiver Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.2.

6.4. eDelivery AS4 Dynamic Sender in Point-to-Point Exchanges Conformance Clause

In order to conform to the eDelivery AS4 Dynamic Sender in Point-to-Point Exchanges Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.3 related to Point-to-Point exchanges.

6.5. eDelivery AS4 Dynamic Sender in Four Corner Exchanges Conformance Clause

In order to conform to the eDelivery AS4 Dynamic Sender in Four Corner Exchanges Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.1.
• Conform to all normative statements and requirements in section 4.3 related to Four Corner exchanges.

6.6. eDelivery AS4 Pull Feature Conformance Clause

In order to conform to the eDelivery AS4 Pull Feature Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.4.

6.7. eDelivery AS4 Large Message Splitting and Joining Conformance Clause

In order to conform to the eDelivery AS4 Large Message Splitting and Joining Feature Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.5.

6.8. eDelivery AS4 ebCore Certificate Update Conformance Clause

In order to conform to the eDelivery AS4 Agreement Update Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.6.2.

6.9. eDelivery AS4 ebCore Endpoint Update Conformance Clause

In order to conform to the eDelivery AS4 Endpoint Update Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in sections 4.6.2 and 4.6.3.

6.10. eDelivery AS4 Alternative Elliptic Curve Cryptography Option Conformance Clause

In order to conform to the eDelivery AS4 Alternative Elliptic Curve Cryptography Option Conformance Clause, an implementation MUST:

• Conform to the eDelivery AS4 Common Profile Conformance Clause in section 6.1.
• Conform to all normative statements and requirements in section 4.7.

7. Ownership

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 https://www.entsog.eu/interoperability-and-data-exchange-nc. 

Parts of the implementation guidelines in this specification, in particular the Four Corner Enhancement, are derived, with permission, from e-CODEX specifications. e-CODEX can be contacted at https://www.e-codex.eu/.

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 initially in the context of the CEF Programme and then of the Digital Europe Programme.

The Dynamic Receiver and Dynamic Sender Profile Enhancements introduced in version 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.

8. References

[AES] Advanced Encryption Standard. FIPS 197. NIST, November 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

[AP] C. Ferris et al. WS-I Attachments Profile Version 1.0. Final Material. 2006-04-20. http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

[ASiC] EN 319 162 part 1 and 2 Version 1.1.1. ETSI Standard, 2016-04. https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf and https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p0.zip and https://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf

[AS4] J. Durand and P. van der Eijk. AS4 Profile of ebMS 3.0 Version 1.0. OASIS Standard, 23 January 2013. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/

[BCP14] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels and Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. https://www.rfc-editor.org/info/bcp14

[BDEW AS4] BDEW Profile. AS4-Nutzungsprofil zum Datenaustausch für regulierte Prozesse in der Energiewirtschaft Version 1.0. BDEW, 01.09.2022. https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=1608&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=5fbee16dcbd284d5f9899875d50353de

[BSI TR-02102-1] Cryptographic Mechanisms: Recommendations and Key Lengths Version 2023-1. BSI Technical Guideline, January 9, 2023. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html

[BSI TR-02102-2] Cryptographic Mechanisms: Recommendations and Key Lengths: Use of Transport Layer Security (TLS) Version: 2023-1. BSI Technical Guideline, January 17, 2023. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.html

[BP20] T. Rutt et al. Basic Profile Version 2.0. OASIS Committee Specification. http://docs.oasis-open.org/ws-brsp/BasicProfile/v2.0/BasicProfile-v2.0.pdf

[ECRYPT CSA] H2020-ICT-2014 – Project 645421. Algorithms, Key Size and Protocols Report (2018). https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf

[eDelivery-EBCOREP-v2] eDelivery ebCore Party Id Type Profile Specification version 2. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+ebCore+Party+Id

[eDelivery-SMP-2] eDelivery SMP Profile Specification version 2. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+SMP

[ebcore-au-v1.0] P. van der Eijk and T. Kramer. ebCore Agreement Update Specification Version 1.0. OASIS Committee Specification, 18 September 2016. http://docs.oasis-open.org/ebcore/ebcore-au/v1.0/cs01/ebcore-au-v1.0-cs01.html. Latest version: http://docs.oasis-open.org/ebcore/ebcore-au/v1.0/ebcore-au-v1.0.html

[ebcore-ep-draft-2023-02] P. van der Eijk. ebCore Endpoint Update. Submission to ebCore TC. https://www.oasis-open.org/committees/document.php?document_id=70798&wg_abbrev=ebcore

[EBCOREP] D. Moberg and P. van der Eijk. OASIS ebCore Party Id Type Technical Specification Version 1.0. OASIS Committee Specification, 28 September 2010. http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/

[EBMS3] P. Wenzel. OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features. OASIS Standard, 1 October 2007. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.pdf

[EBMS3P2] J. Durand et al. OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features. OASIS Committee Specification, 19 May 2011. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/ebms-v3-part2.pdf

[EBERRATA] OASIS ebXML Messaging TC Issue Tracker https://tools.oasis-open.org/issues/browse/EBXMLMSG

[ENTSOGAS4] ENTSOG AS4 Usage Profile. https://www.entsog.eu/interoperability-and-data-exchange-nc

[GLN] GS1 Global Location Number (GLN). https://www.gs1.org/standards/id-keys/gln

[IANACC] IANA HTTP Content Coding Registry. https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding

[ISO 15000-1] ISO 15000-1:2021. Electronic business eXtensible Markup Language (ebXML) — Part 1: Messaging service core specification. ISO Standard, 2021-02. https://www.iso.org/standard/79108.html

[ISO 15000-2] ISO 15000-2:2021. Electronic business eXtensible Markup Language (ebXML) — Part 2: Applicability Statement (AS) profile of ebXML messaging service. ISO Standard, 2021-02. https://www.iso.org/standard/79109.html

[NIST 800-52r2] Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. NIST Special Publication 800-52 Revision 2. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf

[RFC1952] P. Deutsch. GZIP file format specification version 4.3. IETF RFC 1952, May 1996. https://www.rfc-editor.org/rfc/rfc1952.html

[RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, January 1998. https://www.rfc-editor.org/rfc/rfc2119.html

[RFC2392] E. Levinson. Content-ID and Message-ID Uniform Resource Locators. IETF RFC 2392, August 1998. https://www.rfc-editor.org/rfc/rfc2392.html

[RFC5246] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. IETF RFC 5246, August 2008. https://www.rfc-editor.org/rfc/rfc5246.html

[RFC6176] S. Turner and T. Polk. Prohibiting Secure Sockets Layer (SSL) Version 2.0. IETF RFC 6176, March 2011. https://www.rfc-editor.org/rfc/rfc6176.html

[RFC8174] B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF RFC 8174, May 2017. https://www.rfc-editor.org/rfc/rfc8174.html

[RFC8410] S. Josefsson and J. Schaad. Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure. IETF RFC 8410, August 2018. https://www.rfc-editor.org/rfc/rfc8410.html

[RFC8446] E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446, August 2018. https://www.rfc-editor.org/rfc/rfc8446.html

[RFC9231] D. Eastlake 3rd. Additional XML Security Uniform Resource Identifiers (URIs). IETF RFC 9231, July 2022. https://www.rfc-editor.org/rfc/rfc9231.html

[RFC9231bis] D. Eastlake 3rd. Additional XML Security Uniform Resource Identifiers (URIs). draft-eastlake-rfc9231bis-xmlsec-uris-03. https://datatracker.ietf.org/doc/draft-eastlake-rfc9231bis-xmlsec-uris/. 

[RFC9325] Y. Sheffer, P. Saint-Andre and T. Fossati. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). IETF RFC 9325, November 2022. https://www.rfc-editor.org/rfc/rfc9325.html

[SECCONTROLS] Security Controls Guidance. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/Security+Controls+guidance

[SOAP12] M. Gudgin et al. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommendation, April 2007. http://www.w3.org/TR/soap12-part1/

[TLSSP] Transport Layer Security (TLS) Parameters. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

[WSSSMS] A. Nadallin et al. OASIS Web Services Security: SOAP Message Security Version 1.1.1. OASIS Standard, May 2012. http://docs.oasis-open.org/wss-m/wss/v1.1.1/wss-SOAPMessageSecurity-v1.1.1.doc

[WSSSWA] F. Hirsch et al. OASIS Web Services Security: Web Services Security SOAP Message with Attachments (SwA) Profile Version 1.1.1. OASIS Standard, May 2012. http://docs.oasis-open.org/wss-m/wss/v1.1.1/wss-SwAProfile-v1.1.1.doc

[WSSX509] A. Nadallin et al. OASIS Web Services Security: Web Services Security X.509 Certificate Token Profile Version 1.1.1. OASIS Standard, May 2012. http://docs.oasis-open.org/wss-m/wss/v1.1.1/wss-x509TokenProfile-v1.1.1.doc

[XMLDSIG] D. Eastlake et al. XML Signature Syntax and Processing (Second Edition). W3C Recommendation, 10 June 2008. https://www.w3.org/TR/xmldsig-core/

[XMLDSIG1] D. Eastlake et al. XML Signature Syntax and Processing Version 1.1. W3C Recommendation, 11 April 2013. http://www.w3.org/TR/xmldsig-core1/

[XML10] T. Bray et al. Extensible Markup Language (XML) 1.0. W3C Recommendation, 26 November 2008. http://www.w3.org/TR/REC-xml/

[XMLENC] D. Eastlake et al. XML Encryption Syntax and Processing. W3C Recommendation, 10 December 2002. http://www.w3.org/TR/xmlenc-core/

[XMLENC1] D. Eastlake et al. XML Encryption Syntax and Processing Version 1.1. W3C Recommendation, 11 April 2013. http://www.w3.org/TR/xmlenc-core1/

9. Contributors

The eDelivery team is in charge of maintaining the current version of the specifications.

Details about contributors of previous versions of this specification is available from e-SENS.

10. History

Details about previous versions of the specifications can be consulted on the e-SENS website.