European CommissionISA Joinup SoftwareSpocs › Starter Kit

eDelivery - Overview

The SPOCS eDelivery concept defines an interoperability layer to interconnect secure and trustworthy eDelivery systems established in the EU Member States. The different solutions are connected via Gateways, which are Web Services communicating via a common SOAP profiling as specified by ETSI TS 102 640 SOAP binding profile, part of the ETSI "Registered E-Mail (REM)" specification.

The picture below shows a snapshot of solutions connected mid 2012; Romania signalled plans to join in course of 2012.

SPOCS eDelivery Network Snapshot

eDelivery Gateway

SPOCS provides a generic Gateway where national eDelivery solutions have to be connected to via an adapter to facilitate the mapping of domestic message format and packaging to the one used on the interoperability layer.
The Gatways must account for the mapping of organisational, semantical and technical layers in the different eDelivery realms:

Mapping Layers

For the technical and semantical layer, a comfortable Java API is provided for converting in- and outbound messages from/to the respective domestic format. On the organisational layer, a base conformance level is defined and provions are given to establish mutual trust.

Interconnect Protocol

For the „SPOCS Interconnect“ interoperability layer, the Web Services protocol stack has been chosen as the base technology set. For serving the particular SPOCS requirements appropriate protocols or protocol extensions have been designed, all based on SOAP, WS-Addressing, WS-Security and underlying mechanisms for message security, SAML token profiled according STORK for authentication, HTTP, SSL/TLS and other proven technologies.
A "normalized" message format is defined, enabling the mapping of domestic message structuring/packaging formats to the SPOCS interconnect one and vice versa. First of all, this concept addresses meta information related to the payload. Many automated processes rely on meta data for further processing and distribution outside the core transport infrastructure, thus provisions must be given for interoperable cross-solution mapping of such information.
In course of the SPOCS project, the protocol was standardised by ETSI ESI as TS 102 640 "SOAP binding profile" mentioned above.

Evidences to control message delivery status

According the REM specification, SPOCS eDelivery uses REM Evidences for control, proof or notification of the dispatched message flow. In a nutshell, evidences provide for a valid proof of end-to-end message delivery. Alike the message itself, evidences can be converted from/to the corresponding domestic format for delivery status control information.

SAML Token used for end entity authenticity attestation

National solutions use different mechanisms and token for attesting authenticity of end entities. For this purpose, SPOCS eDelivery uses SAML-Token as specified by the OASIS "Security Assertion Markup Language" specification, used in a profiling like provided by the STORK LSP. Again, alike for the message itself, SAML token can be converted from/to the corresponding domestic format/mechanisms for authenticity attestation.

SPOCS Trust List to establish cross-solution trust

National Gateways are seen as part of the national trust domains. A single Gateway in a trustworthy manner somewhat is acting "on behalf" of the eDelivery domains/realms using this specific instance to interconnect to foreign solutions; to establish trust between the solutions interconnected via Gateways, trust must be established between these different Gateways. eDelivery Gateways must be registered in a SPOCS Trust List according to ETSI TS 102 231, among other attributes exposing X509v3 certificates used by the Gateways for SSL handshake and message signing. This transport signature is checked by a receiving Gateway to control if the sending Gateway is a trusted one inside the SPOCS Interconnect trust circle.

The eDelivery open modules provide following functionalities:

  • API to convert messages between domestic format and the one used on the interoperability layer ("REMDispatch")
  • Validation of correct format of messages / message parts
  • Application and Validation of signatures applied to messages / message parts
  • Generation of Evidences, access to such objects and contained elements and attributes
  • Generation of SAML token attesting end entity authenticity, access to such objects and contained elements and attributes
  • Transparent target Gateway discovery on base of recipients's eDelivery domain
  • Trust establishment/validation between Gateways: transparent handshake with SPOCS TL

The present documentation consist of following sections:

Support

For support information please see Contact.