Contents

 Four Corner Topology in OOTS

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.

 Routing Metadata

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 is required if the party identifier is not a URI. Unless otherwise specified for specific domain profiles, the value urn:oasis:names:tc:ebcore:partyid-type:unregistered SHOULD be used.

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.

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: fixed value: urn:oasis:names:tc:ebcore:partyid-type:unregistered unless specified otherwise by a domain.
• 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 that is sending the message. Note: When the AP services multiple competent authorities, this parameter can also be set dynamically to prevent that, for each competent authority, a separate P-Mode is needed (which only differs for this parameter).
• PMode[].BusinessInfo.Properties[originalSender]/@type : not used.
• 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.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: fixed value: urn:oasis:names:tc:ebcore:partyid-type:unregistered unless specified otherwise by a domain.
• 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 for whom the AP is receiving the message.
• PMode[].BusinessInfo.Properties[finalRecipient]/@type : not used.
• 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.

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

The rest of the PMode attributes remain unchanged.

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 - Q3 2022,  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. 

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.

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.

Access Point Interconnectivity

For OOTS, eDelivery form a point-to-point exchange network of Access Points that are fully preconfigured 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.

 References

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