Information Mediator vs. e-Delivery

Information Mediator vs. e-Delivery

 

Feature

GovStack Information Mediator Specification

eDelivery Specification

Primary Goal

Interoperable data exchange within a digital government's ecosystem, connecting various reusable "building blocks."

Secure, reliable, and trusted cross-border electronic data exchange, primarily within the EU.

Architectural Model

Gateway/Hub-and-spoke model; a component within a larger, holistic government architecture.

Distributed peer-to-peer network based on Access Points.

Core Components

Service Access Layer, Directory Services, Pub/Sub Service, and Logging/Monitoring.

AS4 Access Points, Service Metadata Publisher (SMP), and Service Metadata Locator (SML).

Basis

Part of the GovStack framework, which promotes a modular, reusable approach for digital public infrastructure.

A well-defined set of profiles based on established international standards (OASIS AS4, BDXL, etc.).

Geographic Focus

Global, with a focus on assisting countries, particularly those with limited resources, in their digital transformation journeys.

Primarily the European Union, facilitating the Digital Single Market.

Flexibility

Highly flexible and designed to be adapted to different national contexts and technological stacks.

Structured and based on specific, profiled standards to ensure strict interoperability and legal compliance.

 

eDelivery is built on a distributed network of nodes called Access Points. The communication is based on the AS4 messaging protocol. Key functionalities and components:

  • AS4 Access Points: Act as gateways for sending and receiving messages over the internet. They handle security, message reliability, and routing.

  • Service Metadata Publisher (SMP): A directory service that allows network participants to publish metadata about their services, such as their Access Point's URL and business capabilities.

  • Service Metadata Locator (SML): A central directory that maps a participant's identity to their corresponding SMP, enabling dynamic discovery of services.

  • The architecture is decentralized, with each participant running their own Access Point that conforms to the eDelivery specifications.

 

Harmonizing the GovStack Information Mediator and eDelivery specifications?

 

1. Treat eDelivery as a "Bridging" or "External" Building Block

 

  • Information Mediator as an eDelivery Access Point: The GovStack Information Mediator's reference implementation (X-Road instance, for example) could be extended to include the functionality of an eDelivery Access Point. This would mean it must be able to:

    • Send and receive messages using the AS4 protocol.

    • Query and publish metadata to an SMP (Service Metadata Publisher) and SML (Service Metadata Locator).

    • Implement the necessary security and reliability features of the eDelivery standard.

  • API Standardization: The GovStack Information Mediator's internal API would remain consistent, providing a standardized REST or OpenAPI interface to other GovStack building blocks. The Information Mediator would then act as an "adapter" or "translator," converting requests from the internal GovStack API format into the AS4 messages required by eDelivery.

2. Establish a Common Messaging Profile

 

While GovStack is designed to be protocol-agnostic, a specific messaging profile should be defined that aligns with eDelivery's requirements.

  • Payload and Metadata Alignment: GovStack can define standard data structures and metadata for common use cases (e.g., e-invoicing, digital health records) that are compatible with the formats used in eDelivery networks (such as the PEPPOL BIS standards). This ensures that the data itself is understandable by both systems.

  • Security and Trust Framework: A key part of harmonization would be aligning the security and trust models. This means defining how digital certificates, trust lists, and message signatures from a GovStack-based system can be recognized and validated by an eDelivery Access Point, and vice versa. This is crucial for cross-border and cross-organizational trust.

 

3. Reference Implementations and Documentation

 

  • Develop a "GovStack-eDelivery Connector": Create an open-source reference implementation of a connector or adapter that demonstrates how a GovStack Information Mediator can be configured to communicate with an eDelivery Access Point. This would provide a blueprint for any country to follow.

  • Update Specifications: The GovStack Information Mediator specifications should be updated to explicitly mention and provide guidance on how to implement eDelivery interoperability. This includes defining the necessary functional and non-functional requirements for such a bridge.

  • Provide Concrete Use Cases: Develop and document a "Reference Use Case" where a digital service built with GovStack needs to exchange data with a service in the EU using eDelivery (e.g., a country's e-Invoicing system, built on GovStack's Payments building block, needs to send an invoice to a company in a European country).