1. Usage of ebMS in a Four-Corner-Model e-CODEX specifications

2. Scope Addressing (of end entities) Reliability Trust establishment / Security Gateway Authentication End Entity Authentication (Original Sender) ebMS-specific Message parts Message Exchange patterns Non-repudiation between gateways (REM evidences)

3. Addressing (of end entities) Currently custom properties in the ebMS header are used (FromPartyId, FromPartyIdType). In parallel e-CODEX also uses SBDH headers on the business level End entity addresses are transmitted in the proprietary format used at the national level. This does not in all cases permit deduction of the appropriate gateway

4. Reliability ebMS permits 3 different and incompatible reliability modules e-CODEX wanted to use WS-Reliability 1.1 as that comes out of the box with Holodeck Unfortunately we couldn‘t make the current Holodeck implementation work WS-ReliableMessaging seems an obvious candidate, but has known interoperability problems e-CODEX is now looking into AS4 receipts

5. Trust establishment / Security Gateway Authentication WS-Security certificates (X509 v3), exchanged manually and statically configured Dynamic discovery of certificates desired, but possibly not per message (semi-automated configuration when new communication partners join the community) End Entity Authentication (Original Sender) SAML-token specified but currently not used What is really the purpose of this?

6. ebMS-specific Message parts (XML, Container with signed PDF, (SAML token)) e-CODEX specs require a particular order of message parts (probably not necessary) Specific values for PayloadInfo / PartInfo are also foreseen Message Exchange patterns Holodeck supports push and pull (AS4-conform) e-CODEX really only uses push For future use cases synchronous MEPs will be examined