Introduction

Bogdan Dumitriu (BD) from DIGIT

BD welcomed attendees, noting the Forum’s growing interest and briefly summarising the 2024 meetings (archive here), including Interoperability Events, and announcing the next 2025 meeting date.

Have your say!

• BD invited participants to introduce themselves, their organisations, and to share what they hoped to gain from the Forum.
• Several participants took the floor to share their interests and objectives related to the eDelivery Interoperability Forum such as news about eDelivery in general and eDelivery specifications in particular, eDelivery conformance testing, eDelivery in the context of Peppol, operating eDelivery networks and staying connected with other users.
• BD encouraged participants to reach out after the meeting to share suggestions on how the Forum could serve them better.

Specifications update

• BD presented the updated eDelivery 2.0 profile roadmap, noting the plan to approve new specifications on 4 December 2024, paving the way for rollout in products in 2025.
• BD summarised key public consultation comments, focusing on adjustments for security protocols and cryptographic standards; emphasised use of X25519 key exchange, SMP for key agreement, and EdDSA vs. ECDSA considerations.
• BD provided updates on Interoperability Events:
  • Three sessions were organised to test early implementations of the new specifications; five products participated (in the meeting, six products were erroneously announced), with successful interoperability mainly among three products, including the European Commission’s sample implementation.
  • A participant asked whether the products successfully tested during the Interoperability Events were built on different platforms or used common cryptographic libraries; an Interoperability Event participant explained that one of the products is based on Node.js and uses different libraries from the Java ones used by Domibus; PE added that the third company uses both Java and .NET, but that it was unclear which of the two the PoC tested in the event was based on.
  • Given that the eDelivery Conformance Testing service would not be ready for testing the new specifications until 2026, BD said the eDelivery team is considering building and publishing tools in early 2025 to allow self-testing. The tools should aid in testing and troubleshooting the implementation of the new cryptographic algorithms.
• PE explained AS4, SMP and BDXL specifications changes introduced in the most recent drafts:
  • Modifications include X25519 key sharing, security token reference adjustments, and Dynamic Discovery update for both C3- and C4-based lookups.
  • A participant asked about the term “valid signing key” and how to verify its validity; PE explained that it is a key recognised by the party, typically the signing key, but specifics are out of scope for the profile; the participant suggested rephrasing to avoid confusion about how to check validity; BD confirmed the language would be reviewed to remove potential confusion.
  • A participant asked about the change regarding security token references, asking if other options are acceptable; PE confirmed that while the profile recommends a standard approach (“SHOULD”), other standards-compliant options are acceptable.
• PE introduced an upcoming public consultation on a potential new AS4 feature to address compression and non-repudiation issues:
  • Compression in AS4 complicates non-repudiation because is non-deterministic, making it difficult to reproduce compressed data for verification.
  • Proposed solution is to add three new part properties to store the digest of uncompressed data, allowing verification without storing compressed data.
  • Full details and several options would be provided in a document that would be launched for public consultation tentatively on 4 November 2024.
  • A participant raised concerns about the proposed solution (another participant supported this concern in the chat) and suggested disabling compression or using HTTP-level compression to avoid the issue without adding complexity; the participant expressed concern that the proposal adds overhead and that there was no open discussion among implementers; BD acknowledged the participant’s point and suggested that feedback be provided during a public consultation (launched on 5 and available here); BD also mentioned time constraints but expressed willingness to consider organising an open discussion if (has been published after the meeting and available here).

eDelivery updates

• BD showed the eDelivery AS4-conformant solutions page, explaining the sorting criteria of products tested with 2023.06 version and later patches; encouraged participants to update their solution information to ensure accurate display; BD shared that a conformance testing service patch version would be deployed soon, adding PKI path token support and addressing minor fixes; reaffirmed eDelivery’s commitment to improvement in its conformance testing service and transparency in sharing AS4 user needs.
• BD outlined plans for including community-provided content in the eDelivery newsletter beginning in Q1 2025; eligibility for content submissions will be limited to conformant solutions tested in the last three years, with strict editorial guidelines and focus on relevant, compliant content.

Presentation of an eDelivery-based ecosystem: European Maritime Single Window environment (EMSWe)

• RP described the context of the European Maritime Single Window (EMSWe), established by the Regulation (EU) 2019/1239 aiming to harmonise rules for providing the information required for port calls, particularly by ensuring that the same data sets can be reported to each Maritime National Single Window in the same manner.
• RP explained the EMSWe's components that included the four-corner model implementation with AS4 Access Points, security features like ASiC containers and the DSS library, and the Common Addressing Service (CAS) for endpoint management.
• A participant asked about the duplication of signatures in AS4 and ASiC containers; RP replied that AS4 signatures validate trusted endpoints between C2 and C3, while ASiC containers provide end-to-end validation from the declarant (C1) to the Member State (C4).
• Another participant inquired whether C2 operators need to be registered to operate within the network; RP confirmed that C2 operators must be registered by Member State administrators.
• A further question was raised about the provision of AS4 solutions to economic operators and potential competition with government-provided solutions; RP and RA clarified that the European Commission does not provide AS4 solutions for senders (C2), leaving it to the market, and that Member States are responsible for informing and facilitating solutions for declarants.
• BD asked whether there were any public resources where participants could find additional information on the EMSWe; RP provided a link accessible with an EU Login account, where further details on the EMSWe and implementation resources could be found.