VERSION 1.0.1 MANDATORY

Contents

 1. Use of eDelivery AS4 

In this version of OOTS, implementations of eDelivery for OOTS must support the following features of eDelivery AS4 1.15:

• the Common Profile 
• the Four Corner Profile enhancements  

These are defined in chapter 3 and 4.1 and the conformance clauses 6.1 and 6.2 of eDelivery AS4 1.15. 

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 Access Points exchange messages on behalf of other parties. This message exchange pattern is also followed in OOTS. 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, which can be:
  • The Evidence Requester that submits an Evidence Request Query;
  • The Evidence Provider submitting an Evidence Response asynchronously to an Evidence Request Query.
• 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, which can be:
  • the Evidence Provider that receives the Evidence Request Query;
  • the Evidence Requester receiving an Evidence Response asynchronously to an Evidence Request Query.

 2. Routing Metadata

2.1 Party Identification

When used in a Four Corner topology, the sender and receiver of the ebMS messages are the Access Points that act on behalf of the Evidence Requester and Provider. This implies that the ebMS message header by default contains the Access Point identifiers as sender and receiver. Using an eDelivery AS4 profile enhancement, however, the outer corners, i.e. the Evidence Requester and Provider, can be included in the ebMS message header. In these enhancements, the ebMS3 message property mechanism includes the identifiers of C1 and C4. This allows the use of arbitrary property-value pairs in an AS4 message and is independent of payload format or structure.

When used in a Four Corner typology:

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

For the identification of the Access Points in the ebMS message header, i.e. the values to be used in the //To/PartyId element are extracted from the DSD Response as shown in the table below. As the sender of the message in a Four Corner architecture,needs to "find" the Access Point used by the receiving party, the receiving AP's identifier is determined on runtime.

As specified in section 5.2.2.4 of [EBMS3], the type attribute of the PartyId element is required if the party identifier is not a URI. Unless otherwise specified for specific domain profiles, the default value urn:cef.eu:names:identifier:EAS:[Code] SHOULD be used. If there is no appropiate EAS scheme for the postfix, the unregistered option urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code] MAY be also used togehter with a ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ postfix.

Properties  in ebMS3 may have a type property as explained at issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2. This property is not present in the XSD published at https://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms-header-3_0-200704.xsd. A patched version of the ebMS3 header XML schema that reflects the resolution of the OASIS issue that can be used to validate the eb:Messaging header is available from https://code.europa.eu/oots/tdd/tdd_chapters/-/tree/master/OOTS-EDM/xsd/ebms3. 

If the type attribute is present on the originalSender and/or finalRecipient message properties and derived from a DSD query response, its value MUST match the value of the corresponding schemeID attribute in the DSD response data. 

2.2 DSD Derived Routing Metadata

The OOTS eDelivery architecture consists of multiple statically pre-configured Access Points. Although the configuration of the APs is static, the receiving endpoint is dynamically provided using the DSD Response. So although the list of APs and their configurations is static, a Data Service can dynamically change between existing APs by updating the AP identifier in the DSD.  Using a DSD lookup, the Evidence Requester is able to extract the necessary metadata to match with a pre-existing PMode. The following table specifies the PMode parameters that are mapped from specific DSD Access Service Metadata Elements.

2.3 Static Routing Metadata

The above section defines how the sender should configure its AS4 gateway's PMode parameters related to the receiver to set up the message exchange with the receiver. Besides these dynamically set parameters, there are also PMode parameters on both the sender and receiver side, which relate to the parties themselves or which values are predefined by the eDelivery profile and independent of the counterparty. These parameters can, therefore, be statically configured. The next two paragraphs specify the statically configured PMode parameters, which are profiled specifically for the OOTS eDelivery architecture.

Sender

For the Sender, the following PMode parameters can be statically configured:

• PMode[].Initiator.Party : TBD.
• PMode[].Initiator.Party/@type: The default value urn:cef.eu:names:identifier:EAS:[Code] SHOULD be used. If there is no appropiate EAS scheme for postfix, the unregistered option urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code] MAY be also used togehter with a ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ postfix.
• PMode[].Initiator.Role : MUST be set to fixed value http://sdg.europa.eu/edelivery/gateway.
• PMode[].BusinessInfo.Properties[originalSender]: the identifier of the competent authority or intermediary platform that is sending the message. Note: When the AP services multiple competent authorities or or intermediary platforms, this parameter can also be set dynamically to prevent that, for each competent authority or or intermediary platforms, a separate P-Mode is needed (which only differs for this parameter).
• PMode[].BusinessInfo.Properties[originalSender]/@type : The default value urn:cef.eu:names:identifier:EAS:[Code] SHOULD be used. If there is no appropiate EAS scheme for postfix, the unregistered option urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code] MAY be also used togehter with a ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ postfix.
• PMode[].BusinessInfo.Service: Follows the rules of the ebXML Messaging Protocol Binding for RegRep Version 1.0
• PMode[].BusinessInfo.Action: Follows the rules of ebXML Messaging Protocol Binding for RegRep Version 1.0
• PMode[].Security.X509.Signature.Certificate: the AP's Certificate. The AP MUST use the Binary Security Token Reference to include the messages' certificate.
• PMode.MEP:  fixed value : http://www.oasis-open.org/committees/ebxml-msg/one-way.

Receiver

For the Receiver, the following PMode parameters can be statically configured:

• PMode[].Responder.Party : TBD.
• PMode[].Responder.Party/@type: The default value urn:cef.eu:names:identifier:EAS:[Code] SHOULD be used. If there is no appropiate EAS scheme for the postfix, the unregistered option urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code] MAY be also used togehter with a ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ postfix. 
• PMode[].Responder.Role : MUST be set to fixed value http://sdg.europa.eu/edelivery/gateway.
• PMode[].BusinessInfo.Properties[finalRecipient] : the identifier of the competent authority or or intermediary platform for whom the AP is receiving the message.
• PMode[].BusinessInfo.Properties[finalRecipient]/@type : The default value urn:cef.eu:names:identifier:EAS:[Code] SHOULD be used. If there is no appropiate EAS scheme for the postfix, the unregistered option urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code] MAY be also used togehter with a ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ postfix. 
• PMode[].Responder.Role : MUST be set to fixed value http://sdg.europa.eu/edelivery/gateway.
• PMode[].Security.X509.Encryption.Certificate : the AP's Certificate.
• PMode[].BusinessInfo.Service: Follows the rules of the ebXML Messaging Protocol Binding for RegRep Version 1.0.
• PMode[].BusinessInfo.Action: Follows the rules of ebXML Messaging Protocol Binding for RegRep Version 1.0.
• PMode[].Security.X509.Signature.Certificate: the AP's Certificate. Like the sender's certificate, the AP MUST use the Binary Security Token Reference to include the messages' certificate.
• PMode.MEP:  fixed value : http://www.oasis-open.org/committees/ebxml-msg/one-way.

In this version of the OOTS, Access Points MUST use a single RSA certificate for both signing and encryption. This reflects the limitations of some widely used eDelivery AS4 access point software implementations. 

2.4 Reverse Routing for Evidence Provider Submission to Evidence Requester

The evidence provider needs to send back the response to the Evidence Requester using eDelivery AS4. To properly route the message back to the Evidence Requester, the Evidence provider access services must apply reverse routing of the received message. Reverse routing is achieved by applying the following rules:

• The Responder Party information of the request message becomes the Initiator Party of the response message
• The originalSender of the request message becomes the finalRecipient of the response message
• The Initiator Party information of the request message becomes the Responder Party of the response message
• The finalRecipient of the request message becomes the originalSender of the response message.

Note: In case of exceptions the originalSender of the response message should be the Error Provider declared in the Evidence Error Response Message. In most cases the Error Provider is the Evidence Provider informing the Evidence Requester about a failed response or missing information or to preform an authentication or preview. However, in case of multiple national routings an error might be created by an intermediate, a technical endpoint (e.g. gateway) as well or by a businesses that has been accredited to supply the evidence. 

The rest of the PMode attributes remain unchanged.

2.5 Message Exchange Pattern

The use of eDelivery is limited to the One Way MEP. OOTS eDelivery messages shall not include a RefToMessageId header.

The initial request message containing an evidence request shall contain a unique, previously unused value for the ConversationId header. A message containing an evidence response or evidence error response shall use as value for the ConversationId header the value used in the corresponding evidence request.

• In the sequence of two request-response exchanges used to support the Preview Service described in 4.9 - Evidence Preview (June 2024),  the request message and evidence response or evidence error response messages in the second request-response pair shall reuse the conversation identifier of the first request-response pair, in order to allow correlation of the two parts of the interaction. 
• If, in the context of a single user session,  multiple requests are issued to a Data Service, the requests shall have the same conversation identifier value.  This allow the Data Service and/or its Preview Space to correlate the request and detect that they relate to the same user session. This may be used to optimize the user experience.  It also allows the tracking and tracing of all evidence exchanges messages for a user session on the side of the evidence requester.
• Late responses are not considered as single user session. They are regarded as a new process. Thus, queries that are made at later times due to unavailability use a new ConversationId. 

Interactive interactions are common in eDelivery deployments with complete round-trip conversations able to be completed in sub-second timings, as demonstrated in test environments like the OOTS Simulator, supporting a good interactive user experience.

2.6 Payload Routing Metadata

When the message exchanged between two Access Points is an EDM Response, it can contain multiple ebMS payloads, one being the main ebXML RegRep response document and the other business attachments referenced from the ebXML RegRep response. To facilitate the processing of the EDM Response by the receiving Access Point, the ebMS header should indicate which payload contains the main ebXML RegRep document and which the attachments. Therefore the sending AP MUST set a part property named MimeType for each payload included in the message. The value of the property MUST be the MIME type of the payload, which for the ebXML RegRep document is defined as application/x-ebrs+xml.

3. Access Point Interconnectivity

For OOTS, eDelivery form a point-to-point exchange network of Access Points that are fully pre-configured and interconnected such that:

• Different sub-networks exist for production and test.
• Within a sub-network:
  • Network security rules (IP whitelists, blacklists) are configured such that any Access Point accepts establishing secure HTTPS connections from any of the other Access Points.
  • Any Access Point can send eDelivery AS4 test messages to, and receive such test messages from, any other Access Point, where test message is a message related to the test service defined in section 3.2.4 of the eDelivery AS4 specification.
  • Evidence Requests can be made from any Access Point to any of the other OOTS Access Points.
  • Evidence Responses and Evidence Error Responses can be made from any Access Point to any of the other OOTS Access Points.

Member States shall deploy at least one Access Point but may deploy multiple Access Points. Each Data Service and Online Procedure Portal instance shall be configured to use at most one Access Point. For Data Services, this configuration is reflected in the Data Service Directory as described in section 2.2 above.

Pre-configuration of Access Points includes the configuration of certificates for message signing and encryption, for every pair of Access Points.  As explained in the eDelivery AS4 specification, the test service can be used to verify the proper configuration of network security (firewall rules etc.) and of eDelivery configurations (trusted certificates, algorithms etc.). In the terminology if the eDelivery Trust Models Guidance Document, OOTS implements a trust model based on Mutual Exchange.

For signing and encryption, Access Points shall use certificates meeting the requirements and recommendations regarding the Digital Certificates used in eDelivery.

4. Network and Transport Layer Security

For network layer security and transport layer security, eDelivery should apply security as specified in section 3.7. 

5. Payload Profile

Any AS4 User Message for OOTS evidence exchange is a SOAP 1.2 with attachments message as defined in the ebMS3 Core Specification and the ebXML Messaging Protocol Binding for RegRep. 

The message contains the following MIME parts:

• the first MIME part contains a SOAP 1.2 XML structure with an empty SOAP body as required by eDelivery AS4.
• the second MIME part contains a RegRep message. It contains either a RegRep4 QueryRequest or a QueryResponse structure.
• If the QueryResponse is an evidence response as described in section 4.5.2 the AS4 action is set to ExecuteQueryResponse.  If it has a non-empty RegistryObjectList, then the AS4 message contains as many additional MIME parts as there are RegistryObject elements in the RegistryObjectList.
  • For each RegistryObject there must be exactly one MIME part that has a MIME content identifier with value set to the value set by the RepositoryItemRef in the RegistryObject.
  • For each additional MIME part there must be exactly one RegistryObject in the RegistryObjectList with a value of its RepositoryItemRef set to the value of the MIME part's content identifier.
• If the QueryResponse is an error response as described in section 4.5.3, the AS4 action is set to ExceptionResponse.

Examples of AS4 headers for evidence requests and responses are provided in section 4.5.4. 

An OOTS Data Service that returns an evidence response message using eDelivery must make sure that:

• The size of each evidence, prior to the GZIP compression applied by AS4, does not exceed 25 MB.
• The MIME type of the evidence SHOULD be one of the MIME types listed in the OOTS Media Types codelist.
• The combined size of all evidences, prior to the GZIP compression applied by AS4, does not exceed 100 MB.

6. References

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/ 

ebXML Messaging version 3 issue tracker. ebMS Core schema correction.  issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2.

ebXML Messaging Protocol Binding for RegRep Version 1.0. OASIS Committee Specification 01. 09 March 2021.  docs.oasis-open.org/ebcore/ebrr-ebms/v1.0/cs01/ebrr-ebms-v1.0-cs01.pdf.

eDelivery AS4 1.15. eDelivery AS4 - 1.15. Last updated: 11 November 2020.

eDelivery Guidance on Certificates. Requirements and recommendations regarding the Digital Certificates used in eDelivery.  Last updated: 02/05/2022. 

eDelivery Trust Models Guidance.  Trust Models Guidance.  Last updated: 11 September 2018. 

OOTS Media Types. https://code.europa.eu/oots/tdd/tdd_chapters/-/raw/master/OOTS-EDM/codelists/OOTS/OOTSMediaTypes-CodeList.gc.