This page provides guidance to (prospective) participants in the eDelivery AS4 2.0 Interoperability Event.

The interoperability event is organized in four stages, with the third being the actual event where the participants meet (virtually) and run the test cases described below. The first two stages are preparatory steps to be performed by the participants in the days/weeks that precede the event, to maximise the useful time spent during the event. The fourth stage is planned to take place after the main event and is intended to offer the participants the opportunity to run detailed analysis of the test results obtained.

Stage 3 (the event) will be organised twice, two weeks apart, giving participants time in the interim to study test results and adjust their implementations if needed.

Stage 1: Participants prepare solutions and share data for Access Point configuration

Preparation of the participants' software and test environments

As soon as a participant decides to attend the event, it is already a good time to start preparing the software component(s) it plans to test during the event.

The preparation would consist of two steps:

a) creating the PoC software to be used during the event (can be started right away)
b) configuring the PoC software to enable communication with the other participants in the event (once the organiser publishes the configuration data and according to this data)

In order to support all participants with point a) the organiser will publish hints and lessons learned from its own effort of developing a PoC here and will similarly share any similar information it receives from participants.

Note: Please consider that the current interoperability event is focused primarily on testing the cryptographic changes introduced by the Common Usage Profile of the eDelivery AS4 Profile version 2.0. Participants also interested in testing the cryptographic options introduced by the profile via the Alternative Elliptic Curve Cryptography Option should prepare additional keys and send additional signature and encryption certificates to be used for this purpose. Testing these alternative cryptographic options will depend on the time available at the end of individual testing sessions. To this end, it is advisable for interested participants to prepare an easy-to-switch-to second configuration profile that uses the Alternative Elliptic Curve Cryptography Option.

Once the participants register for the event

Following their registration to the interoperability event, participants will receive by email from the organiser an invitation to fill in an EU Survey form. The form will collect data about each participant's access point that the other participants require to configure their own eDelivery AS4 implementations in order to establish the access point connections.

The form will ask for following parameters from each participant:

• the publicly visible MSH http URL of the access point, if any. In order to reduce the risk of connection issues, prefer using plain HTTP endpoints during the event and avoid using "whitelisting"-type firewall protection for the test environment.
• the publicly visible MSH https URL of the access point, if any. Participants providing an https URL will be asked in addition to provide the TLS server certificate for the URL.
• checkbox to indicate if the solution used at the event can use plain HTTP when acting as a client sending push messages.
• the signing public certificate. The subject's key for this certificate is required to be of the Ed25519 key type.
• the encryption/key-exchange public certificate. The subject's key for this certificate is required to be of the X25519 key type.
• [optional, for interested participants] an alternative signing public certificate. The subject's key for this certificate is required to be of the EC key type, using the secp256r1 curve.
• [optional, for interested participants] an alternative encryption/key-exchange public certificate. The subject's key for this certificate is required to be of the EC key type, using the secp256r1 curve.

Participants will be asked to provide all certificates in PKCS#7 format. Given that some participants may use EdDSA- or ECDSA-signed certificates (e.g., for self-signed certificates), it is advised that solutions used at the event are capable of validating any of RSA-, EdDSA- or ECDSA-signed certificates.

Please note that the Party ID of each participant will not be requested by the organiser via the form. The organiser will assign a Party ID to each participant. The type attribute of the Party ID will be set to urn:oasis:names:tc:ebcore:partyid-type:unregistered for all parties.

Stage 2: The organiser publishes configuration & test data

Access Point configuration

Aggregated configuration data based on what participants provide in stage 1 will be published in an accessible location linked from the web page of the event.

Each participant should configure its access point to authorise communication with the access points of all the other participants in the event.

The configuration data will take the form of a table listing all the participants along with their assigned Party ID and the access point configuration data they provided (certificates, URL, etc.)

For the collaboration information parameters Service and Action and for the payloads, we propose to use real values from AS4 as used by two domains: ENTSOG (gas transmission operators, https://www.entsog.eu/interoperability-and-data-exchange-nc) and OOTS (Once-Only Technical System, https://ec.europa.eu/digital-building-blocks/sites/display/OOTS/OOTSHUB+Home).

P-Mode parameters

Each participant should pre-configure its solutions using the P-Mode parameters documented in the eDelivery AS4 Profile version 2.0, supplemented by P-Mode values defined for each test case below.

Payloads for AS4 messages

To execute the required test cases during the event, one or more payload files are provided for each test case below.

Stage 3: Testing during the interoperability event

In early June 2024, the organiser will share with registered participants an invitation to a WebEx meeting where testing can take place in pairs in breakout rooms.

The aim of the event is for each participant to execute the test cases below with each other participant. Each pair of participants will have 45 minutes to execute the tests twice (switching roles between initiator and responder). This approach may be revised depending on the eventual number of participants.

Each pair of participants (participant A, initiator and participant B, responder) should execute the test cases defined hereunder, following the advice for execution.

How to execute a test case

When executing each of the below test cases except for TC00, participants are encouraged to follow these steps:

• the sending AP:
  • builds the HTTP request for the outgoing message in accordance with the eDelivery AS4 profile version 2.0
  • logs the outgoing message before sending it, with the sending party keeping track of the message id, approximate timestamp (or some other means of identification) to ensure it can identify the message in the logs later on
• when called, the receiving AP:
  • logs the incoming HTTP request
  • identifies the sending party through the combination of Party ID and signing certificate declared by the incoming message. (Note that you may encounter certificates signed by RSA-, EdDSA- or ECDSA-type issuer certificates.)
  • authenticates the message by validating the signature of the message
  • [if applicable] decrypts the content of the message by using the key that is referenced in the encryption header
  • [if applicable] logs the decrypted payloads
  • validates that the correct (according to eDelivery AS4 profile version 2.0) cryptographic algorithms were used by the sender AP when constructing the HTTP request:
    • signature algorithm: http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519
    • element/body-part digest for signature: http://www.w3.org/2001/04/xmlenc#sha256
    • payload symmetrical encryption algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
    • key agreement method: http://www.w3.org/2021/04/xmldsig-more#x25519
    • key derivation function: http://www.w3.org/2021/04/xmldsig-more#hkdf
    • key wrapping algorithm: http://www.w3.org/2001/04/xmlenc#kw-aes128
  • builds an AS4 acknowledgment of receipt and an HTTP response message to include the acknowledgement
  • logs the HTTP response before returning it
    
• the sending AP:
  • logs the received acknowledgment response
  • validates the acknowledgment by validating the certificate and the link of the certificate to the receiver's Party ID
  • validates the signature of the acknowledgement and validates that the correct signature algorithm was used (i.e., http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519)

Note: if, for any reason, the steps above cannot be carried out as described, a technical error should be raised and logged along with the stack trace at the point the error occurred.

Test result form

When executing the test cases, to document and assist with post-event (self and joint) assessment, the pair of participants are kindly asked to fill in a test result form. The empty (template) result form is available here: (eDelivery).(2024-06-11).(eDelivery Interoperability Event).(Test results form template).(Party A - Party B).(v1.0).xlsx

During or after the event the parties are invited to send the filled-in forms to the event organiser at EC-EDELIVERY-SUPPORT@ec.europa.eu.

A few days after the event, the organiser will publish and share with all participants the filled-in forms for assessment.

Test Case: TC00 – Network connectivity

Description:

Testing of the network connection. A basic http connection test should be carried out between the parties. Party B will be the server and Party A the client. Party A will send an HTTP POST request to Party B's MSH URL. The server needs to be reachable and should respond with any HTTP code. Any tool can be used to send the HTTP POST request.

Purpose:

This is a preparatory test case, only meant to reduce the time spent troubleshooting network connection issues during the other test cases.

To the extent possible, participants are encouraged to run TC00 in the days that precede the main event. Participants interested to do so are invited to let the event organiser know by writing to EC-EDELIVERY-SUPPORT@ec.europa.eu, also providing their consent that their email address can be shared with the other participants interested in pre-event execution of this test case.

Regardless if run before or during the event, the test case should be run in both directions.

Test Case: TC01 – Minimal AS4 Message Exchange

Description

Party A sends an AS4 test message with no payload to Party B.

Purpose

This test case is intended to test:

• the overall connectivity
• the ability of the sending access point to sign the message using the new cryptography primitives
• the ability of the receiving access point to validate the signature of the message

P-Mode configuration

Payload

No payload.

Test Case: TC02 – ENTSOG sample message with single payload

Description

Party A sends an AS4 user message with a single payload to Party B.

Purpose

This test case is intended to test:

• the ability of the sending access point to encrypt the payload and sign the message using the new cryptography primitives
• the ability of the receiving access point to validate the signature of the message and decrypt the payload

P-Mode configuration

Payload

Please use the following file: Edig@s_payload.xml

Test Case: TC03 – OOTS sample message with two payloads

Description

Party A sends an AS4 user message with two payloads to Party B.

Purpose

This test case is intended to test:

• the ability of the sending access point to encrypt the payloads and correctly reference the encryption key used to encrypt the two separate payloads and sign the message using the new cryptography primitives
• the ability of the receiving access point to validate the signature of the message and to correctly read the encryption key references and use them to decrypt the payloads

P-Mode configuration

Payload

Please use the following two files: OOTS_payload1.xml and OOTS_payload2.pdf

Stage 4: Results analysis & publication

During or after the event the parties are invited to send the filled-in forms to the event organiser at EC-EDELIVERY-SUPPORT@ec.europa.eu.

A few days after the event, the organiser will publish and share with all participants the filled-in forms for assessment.

As the analysis progresses, participants are encouraged to share any observations and lessons learned by email or directly via page comments. This process should help address implementation issues, clarify the eDelivery AS4 profile version 2.0 where needed and prepare the second round of the event where hopefully all tests can be passed.

After the event, the organiser will compile and publish a report and a news item including the names of the organisations who tested the new profile successfully. Organisations will be asked for their consent during registration and before publication.