# Draft - European Interoperability Framework – Technical Specification (EIF-TS) ## Preamble **Subject: The European Interoperability Framework – Technical Specification (EIF-TS): A Modern Foundation for Europe's Digital Public Services** **1. A New Digital Reality Requires a New Technical Foundation** The European Union is committed to a digital transformation that empowers every citizen and business. The goals set forth in the **Digital Decade Policy Programme 2030**, the realisation of a true Digital Single Market, and the provision of seamless cross-border public services all depend on a single, critical factor: **interoperability**. Our ability for systems, organisations, and nations to work together digitally is no longer a niche technical issue; it is a strategic imperative. The technological landscape has evolved dramatically. The era of siloed, on-premise systems has given way to a new paradigm of **cloud-native platforms, data-driven services, and API-based ecosystems**. This shift demands an updated and unified technical vision. Without a common approach, we risk a future of digital fragmentation, increased cybersecurity threats, and costly vendor lock-in, undermining our shared goals and our technological sovereignty. To address this challenge, we propose to the European Commission the **European Interoperability Framework – Technical Specification (EIF-TS)**. This document serves as the official technical implementation guide for the high-level principles of the European Interoperability Framework (EIF). It provides a concrete, modern, and coherent set of rules for building the next generation of digital public services across the Union. **2. What is the EIF-TS? A Shift from Lists to Patterns** The EIF-TS is more than a simple catalogue of standards. It represents a fundamental shift in how we approach the design and development of public IT systems. Its core innovations are: * **Focus on Architectural Patterns:** Before choosing a technology, we must agree on *how* we build. The EIF-TS introduces a set of mandatory architectural patterns—such as **API-Led Design, Event-Driven Architecture, and Zero Trust Security**—to ensure that all new systems are designed from the ground up to be modular, resilient, and secure. * **Embracing the Cloud-Native World:** The framework provides clear guidance on leveraging modern cloud environments effectively and responsibly. It promotes the use of open standards for **containerisation and orchestration**, enabling portability and preventing dependency on any single technology provider, thus reinforcing the Union's strategic autonomy. * **A Curated Set of Open Standards:** The specification includes a clear, concise list of recommended open standards for every layer of the technology stack—from networking and identity management to data formats and digital signatures. This list has been updated to reflect the current state of the art, retaining what is still relevant from past guidance and integrating new standards essential for today's applications. * **Guidance on Emerging Technologies:** To ensure our public services are future-proof, the EIF-TS provides a common European approach to the adoption of **Artificial Intelligence (AI), Distributed Ledger Technology (DLT), and Post-Quantum Cryptography**, ensuring they are integrated in a way that is interoperable, secure, and aligned with our values. **3. Key Benefits for Public Administrations and Citizens** The adoption of the EIF-TS across the Union would deliver tangible benefits: * **For Citizens and Businesses:** Access to more reliable, secure, and seamless public services that work across borders. The framework is a key enabler of the "once-only" principle and the secure use of the **European Digital Identity (EUDI) Wallet**. * **For Public Administrations:** * **Faster Development:** Reusable patterns and clear standards reduce design time and accelerate project delivery. * **Reduced Costs:** Promoting open-source and open standards lowers licensing costs and increases the pool of potential suppliers. * **Enhanced Cybersecurity:** The mandatory Zero Trust architecture and secure-by-design principles significantly strengthen the posture of public IT systems against modern threats. * **Increased Agility:** Modular systems can be updated and scaled more easily to meet changing policy needs and user expectations. * **For the Digital Single Market:** Removing technical barriers fosters a more competitive and innovative market for digital solutions and strengthens the foundation for a truly integrated European digital economy. **4. Governance and a Call to Action** The EIF-TS is a living document. Its evolution should be managed transparently by a new **European Interoperability Technical Committee (EITC)**, composed of experts from the Commission and Member States. This ensures the framework remains relevant and benefits from the collective expertise of the entire European public sector. The European Commission will adopt the EIF-TS for all its new systems and strongly encourages Member States to do the same, aligning their national interoperability frameworks with this common European standard. We invite all stakeholders—public administrations, technology providers, and academic institutions—to embrace this specification. By building on this common foundation, we can collectively accelerate Europe's digital transformation and deliver the secure, efficient, and citizen-centric public services that our future demands. --- ## Chapter 1: Introduction and Core Principles ### 1.1. Context and Purpose: Building a Coherent Digital Europe The European Union's digital ambition, as enshrined in the **Digital Decade Policy Programme 2030**, is to create a digital future that is human-centric, sustainable, and prosperous. Achieving this vision requires not only policy alignment but also deep technical coherence across the Union. The seamless provision of cross-border public services—a cornerstone of a functioning Digital Single Market—is fundamentally dependent on the interoperability of the underlying digital systems of our Member States. This document, the **European Interoperability Framework - Technical Specification (EIF-TS)**, serves as the definitive technical implementation guide for the high-level principles established in the European Interoperability Framework (EIF). Its purpose is to translate those principles into concrete, actionable guidance for public administrations. It provides a common language and a modern set of rules for architects, developers, and IT decision-makers who are building the digital public services of tomorrow. The technological landscape has transformed radically since previous guidance was issued. The paradigm has shifted from on-premise, monolithic systems towards **cloud-native, API-driven, and data-centric ecosystems**. This evolution presents both immense opportunities and significant challenges, including risks of fragmentation, vendor lock-in, and new security vulnerabilities. The EIF-TS is designed to navigate this new reality, ensuring that the Union's digital infrastructure is built on a foundation of openness, security, and strategic autonomy. By establishing a common technical baseline, this specification aims to: * **Accelerate the development and deployment** of high-quality, user-centric digital public services. * **Enhance cybersecurity and data protection** by promoting secure-by-design architectures and standards. * **Reduce administrative burden and costs** for public administrations and for citizens and businesses interacting with them. * **Foster a vibrant ecosystem of innovation** by promoting open standards that allow for a diverse market of solution providers. * **Strengthen the Digital Single Market** by removing technical barriers to cross-border service provision. ### 1.2. Scope and Applicability The EIF-TS is designed to provide a comprehensive yet flexible framework applicable to a wide range of IT initiatives within the European public sector. Its application is defined as follows: * **Mandatory:** The EIF-TS is mandatory for all new IT systems and major revisions of existing systems that are developed or procured by the Institutions of the European Union. It is also mandatory for all new systems developed within the scope of Union-funded programmes (e.g., Digital Europe Programme) that involve cross-border data exchange or service provision. * **Strongly Recommended:** Member States are strongly encouraged to adopt the EIF-TS as the technical foundation for their national interoperability frameworks. Its application is recommended for all new digital public services developed by public administrations at the national, regional, and local levels to ensure coherence and future-proof their investments. * **Guidance for Modernisation:** For existing legacy systems, the EIF-TS serves as a target architecture. During modernisation, refactoring, or integration projects, administrations should use this specification as a guide to progressively align their systems with modern architectural patterns and standards, prioritising the exposure of legacy functionalities through secure, standardised APIs. This specification does not mandate the use of specific software products but rather the adoption of open standards and architectural patterns that they implement. ### 1.3. Core Principles for Modern Public Services The selection of any technology, standard, or architectural pattern within the scope of this framework must be demonstrably aligned with the following core principles. These principles are interdependent and form the normative foundation of the EIF-TS. #### 1.3.1. Openness This principle ensures transparency, avoids vendor lock-in, and fosters a competitive and innovative market. It is manifested through: * **Open Standards:** Utilisation of technical specifications that are mature, publicly available, royalty-free, and maintained by a non-profit, consensus-based organisation, as defined by the European Interoperability Framework. * **Open Source:** Prioritising the use of open-source software for key infrastructure components and promoting the publication of new publicly funded software under an open-source licence (e.g., EUPL) to encourage reuse and collaboration. * **Open Data:** Making public sector data findable, accessible, interoperable, and reusable (FAIR), where legally and ethically appropriate. * **Open APIs:** Exposing system functionalities and data through publicly documented and stable APIs. #### 1.3.2. Security and Privacy by Design and by Default Security and data protection are not features to be added to a system but are intrinsic to its design. Every system must be architected in full compliance with the Union's legal framework, including the General Data Protection Regulation (GDPR), the NIS2 Directive, the Cyber Resilience Act, and the Digital Operational Resilience Act (DORA). This implies: * Implementing a **Zero Trust security model**. * Applying data minimisation and purpose limitation principles. * Conducting data protection and cybersecurity risk assessments from the earliest stages of a project. * Ensuring the security of the entire software supply chain. #### 1.3.3. API-First To promote modularity, reuse, and seamless integration, all new service components or systems must be designed from an "API-first" perspective. This means that a system's primary interface is its Application Programming Interface (API), which is developed before any specific user-facing application. These APIs must be well-documented, secure, reliable, and versioned. #### 1.3.4. Cloud-Agnostic and Portable To ensure long-term operational resilience and strategic autonomy, public services should be designed to be cloud-agnostic. This principle mitigates the risk of dependency on a single cloud service provider. It is achieved by: * Using open standards for containerisation and orchestration. * Leveraging Infrastructure as Code (IaC) with tools that support multiple cloud targets. * Abstracting dependencies on proprietary cloud services where possible. #### 1.3.5. Data-Centric Data is a strategic asset for creating public value. A data-centric approach means that data is treated as a first-class citizen in system design, independent of the applications that process it. This involves: * Establishing clear data governance, ownership, and quality frameworks. * Using common semantic models and vocabularies to ensure shared understanding. * Making data discoverable through catalogues and accessible via APIs, subject to appropriate access controls. #### 1.3.6. Resilience and Scalability Public services must be reliable and performant, even under stress or in the face of partial system failures. Systems must be architected for: * **Resilience:** The ability to withstand and recover from failures in components or infrastructure. This is achieved through redundancy, decoupling, and graceful degradation. * **Scalability:** The ability to handle variations in load dynamically and cost-effectively, for instance by scaling resources up or down automatically based on demand. #### 1.3.7. User-Centricity The ultimate goal of digital public services is to serve the needs of citizens and businesses effectively and inclusively. This principle, aligned with the **EU Declaration on Digital Rights and Principles**, dictates that technology choices must be driven by the need to create services that are: * **Accessible:** Usable by all, including persons with disabilities. * **Intuitive:** Easy to understand and navigate. * **Proactive:** Anticipating user needs where possible (the "once-only" principle). * **Transparent:** Providing users with clear information about how their data is being used and how decisions are made. ## Chapter 2: Modern Architectural Patterns ### 2.1. Introduction to Architectural Principles The selection of individual standards is secondary to the adoption of sound architectural patterns. A pattern provides a proven, reusable solution to a commonly occurring problem within a given context. By establishing a common set of architectural patterns, the EIF-TS ensures that systems developed across the Union are not only built with interoperable components but are also structured in a way that promotes resilience, scalability, and long-term maintainability. The patterns described in this chapter represent the recommended architectural baseline for all new digital public services. Project teams must justify any significant deviation from these patterns based on specific, documented constraints. ### 2.2. API-Led, Modular Service Architectures The monolithic application model of the past, where all functionalities are tightly coupled within a single deployment unit, struggles to meet the dynamic and complex needs of modern public services. The recommended approach is to design systems as a collection of well-defined, modular services that communicate through APIs. This can be achieved through two primary architectural patterns: the **Modular Monolith** and the **Microservices Architecture**. The choice between these patterns should be a conscious one, based on team size, organisational maturity, and the complexity of the domain. #### 2.2.1. The Modular Monolith (Modulith) For many projects, especially those with smaller teams or less complex domains, the operational overhead of a distributed microservices architecture can be prohibitive. The Modular Monolith offers the design benefits of modularity without the complexity of a distributed system. * **Description:** A Modular Monolith is a single application (a monolith) that is internally structured into distinct, logically separate modules. Each module is responsible for a specific business capability and has a well-defined public interface (API). Crucially, modules are forbidden from directly accessing the internal components (e.g., code, database tables) of other modules; they may only communicate through their public, published interfaces. * **Key Principles:** * **High Cohesion, Low Coupling:** Code related to a single business capability is grouped together within a module. Dependencies between modules are kept to a minimum and are explicit. * **Enforced Modularity:** The boundaries between modules are strictly enforced at the code level, preventing tight coupling and "spaghetti code." * **Single Deployment Unit:** The entire application is deployed as a single process, simplifying operations, testing, and debugging. * **Benefits:** * **Simplicity:** Easier to develop, test, and deploy than a distributed system. * **Consistency:** Data consistency is easier to manage within a single database and transaction. * **Evolutionary Path:** A well-designed modulith can be strategically broken apart into microservices later if and when the need arises, as the logical boundaries are already established. * **Applicability:** This is the recommended starting point for many new projects. It provides a strong architectural foundation while minimising operational complexity. #### 2.2.2. The Microservices Architecture When a domain is highly complex, or when an organisation requires independent scaling and deployment of different business capabilities, a Microservices Architecture is usually a more appropriate pattern. * **Description:** This pattern structures an application as a collection of small, loosely coupled, and independently deployable services. Each service is responsible for a specific business capability and communicates with other services and external clients through well-defined APIs. * **Core Components:** * **Microservices:** Autonomous services that own their own data and logic (e.g., a "Citizen Profile Service" or a "Business Registration Service"). * **API Gateway:** A single, managed entry point for all clients. The gateway is responsible for handling cross-cutting concerns such as request routing, authentication and authorization, rate limiting, and collecting observability metrics. This centralises policy enforcement and simplifies the underlying microservices. * **Benefits:** * **Agility and Speed:** Teams can develop, deploy, and scale individual services independently, leading to faster delivery cycles. * **Technological Diversity:** Each service can be built with the technology stack best suited for its specific task. * **Resilience:** The failure of one service does not necessarily lead to the failure of the entire application, enabling graceful degradation of functionality. * **Applicability:** Recommended for large-scale, complex applications where independent team autonomy, deployment, and scalability are critical requirements. Projects should only adopt this pattern when they have the organisational and operational maturity to manage a distributed system. ### 2.3. Event-Driven Architecture (EDA) While API-led architectures excel at synchronous, request-response interactions, many processes in the public sector are inherently asynchronous. **Event-Driven Architecture (EDA)** is the recommended pattern for these scenarios. * **Description:** In an EDA, services communicate through the production and consumption of *events*. An event is a message representing a significant change in state (e.g., `PaymentReceived`, `ApplicationSubmitted`, `AddressUpdated`). Services publish events to an event broker (or "message bus") without knowing which services will consume them. Other services subscribe to the events they are interested in and react accordingly. * **Core Components:** * **Event Producers:** Services that generate and publish events. * **Event Broker:** A central, reliable middleware that receives events from producers and delivers them to consumers (e.g., a message queue or a streaming log). * **Event Consumers:** Services that subscribe to events and execute business logic in response. * **Benefits:** * **Decoupling:** Producers and consumers are fully decoupled; they do not need to know about each other's existence, location, or implementation. * **Responsiveness and Real-Time Interaction:** Allows for building systems that react to changes in real-time. * **Scalability and Resilience:** The event broker can buffer events if a consumer service is temporarily unavailable, and multiple instances of a consumer can process events in parallel to handle high loads. * **Applicability:** Recommended for notifications, data synchronisation between disparate systems (e.g., updating multiple databases when a citizen's address changes), and long-running business processes. ### 2.4. Cloud-Native Architecture To leverage the full potential of modern cloud computing environments (whether public, private, or hybrid), applications must be designed according to **Cloud-Native** principles. This is not about where an application runs, but *how* it is designed and operated. * **Description:** A cloud-native architecture is one that is containerised, dynamically orchestrated, and built with microservices. It is designed for automation, resilience, and observability. * **Core Pillars:** * **Containerisation:** All application code and its dependencies are packaged into lightweight, immutable, and portable units (containers). This ensures consistency across all environments, from development to production. * **Orchestration:** A container orchestrator (e.g., Kubernetes) is used to automate the deployment, scaling, healing, and networking of containers. * **Infrastructure as Code (IaC):** All infrastructure (networks, virtual machines, databases, load balancers) is defined and managed through machine-readable code (e.g., declarative configuration files) rather than manual configuration. This enables automated, repeatable, and auditable environment provisioning. * **Benefits:** * **Portability:** Applications can be moved between different cloud providers or on-premise data centres with minimal changes. * **Operational Efficiency:** High degree of automation reduces manual effort and the risk of human error. * **Resource Optimisation:** Dynamic scaling ensures that resources are used efficiently, adapting to the current workload. ### 2.5. Modern Data Architecture: The Data Mesh Principle Traditional, centralised data architectures (like the enterprise data warehouse) often create bottlenecks and hinder agility in large, complex organisations like public administrations. For data-intensive applications, this framework recommends adopting principles from the **Data Mesh** pattern. * **Description:** A Data Mesh is a decentralised, socio-technical approach to data architecture. It shifts the responsibility for data from a central data team to the operational domains that produce and understand the data. Data is treated as a product (`Data as a Product`), owned by domain teams and made available to the rest of the organisation through a self-service data platform. * **Core Principles:** * **Domain-Oriented Ownership:** Data ownership is decentralised to the teams closest to the data (e.g., the Ministry of Health owns health-related data products). * **Data as a Product:** Each domain is responsible for creating data products that are findable, addressable, trustworthy, and interoperable. * **Self-Service Data Platform:** A central platform team provides the tools and infrastructure that enable domain teams to build, deploy, and manage their own data products easily. * **Federated Computational Governance:** A global set of rules and standards (for security, privacy, interoperability) is enforced across all data products, ensuring coherence without centralising control. * **Benefits:** * **Scalability:** Scales organisationally by removing the central bottleneck. * **Increased Agility:** Domain teams can innovate and evolve their data products independently. * **Higher Data Quality:** Data quality is improved as it is managed by the domain experts who best understand its context and meaning. ### 2.6. Zero Trust Security Architecture The perimeter-based security model of the past ("trust but verify") is obsolete in a world of distributed services, remote work, and hybrid cloud. The mandatory security architecture for all new systems is **Zero Trust**. * **Description:** Zero Trust is a security model based on the principle of "never trust, always verify." It assumes that no user or device is trustworthy by default, regardless of its location (inside or outside the corporate network). Every access request must be explicitly authenticated and authorised against defined policies before access is granted. * **Core Pillars:** * **Strong Identity:** All users, devices, and services are authenticated with strong, phishing-resistant credentials. * **Micro-segmentation:** The network is segmented into small, isolated zones to prevent lateral movement by attackers. * **Least Privilege Access:** Users and systems are granted only the minimum level of access necessary to perform their specific tasks. * **Continuous Monitoring:** All traffic and activity are logged and analysed continuously to detect and respond to threats in real-time. * **Benefits:** * **Reduced Attack Surface:** Limits the impact of a security breach by preventing attackers from moving freely within the network. * **Secure Remote Access:** Enables secure access for remote and mobile users without relying on traditional VPNs. * **Enhanced Data Protection:** Protects sensitive data by enforcing granular access policies at the application and data level. ## Chapter 3: Technical Interoperability Standards ### 3.1. Introduction to Technical Standards This chapter provides the reference list of open technical standards that form the foundation for interoperability within the European public sector. The selection of these standards is guided by the core principles of openness, maturity, security, and market support, as assessed by the **Common Assessment Method for Standards and Specifications (CAMSS)**. Adherence to these standards is essential for implementing the architectural patterns outlined in Chapter 2. They ensure that components developed by different teams, in different Member States, using different technologies, can communicate and operate together seamlessly and securely. For each domain, a "Recommended" standard is identified as the default choice for new systems. "Supported" standards are acceptable, typically for ensuring backward compatibility or for specific niche use cases. ### 3.2. Network and Transport Layer This layer provides the fundamental connectivity and secure transport for all data exchanges. #### 3.2.1. Network Protocol * **Recommended:** **IPv6** (as defined in IETF RFC 8200). All new systems and network infrastructure must be IPv6-enabled by default. IPv4 is supported only as a transitional measure for backward compatibility. * **Rationale:** IPv6 provides a vastly expanded address space necessary for the proliferation of connected devices (IoT) and simplifies network configuration. #### 3.2.2. Name Resolution * **Recommended:** **DNSSEC (Domain Name System Security Extensions)** (as defined in IETF RFCs 4033, 4034, 4035). DNSSEC must be used to protect against DNS spoofing and cache poisoning, ensuring that users are connected to the authentic public service they intend to reach. #### 3.2.3. Transport Layer Security * **Recommended:** **TLS (Transport Layer Security) 1.3** (as defined in IETF RFC 8446). All communication channels exchanging data over untrusted networks must be encrypted using TLS 1.3. The use of earlier versions is deprecated and should be phased out. * **Supported:** **QUIC v1** (as defined in IETF RFC 9000). As a modern, encrypted-by-default transport protocol, QUIC is supported for performance-critical web applications and APIs. It is the underlying transport for HTTP/3. ### 3.3. Identity, Authentication, and Authorization A unified, secure, and privacy-preserving approach to identity is a prerequisite for cross-border public services. These standards provide the framework for managing the identity of citizens, businesses, and systems. #### 3.3.1. Core Federation and Delegation Protocols * **Recommended:** **OpenID Connect (OIDC) 1.0**. The primary standard for user authentication and identity federation. * **Recommended:** **OAuth 2.1**. The primary standard for delegated authorization. * **Supported:** **SAML (Security Assertion Markup Language) 2.0**. Supported for integration with existing enterprise identity providers. #### 3.3.2. European Digital Identity (EUDI) Wallet Integration * **Mandatory:** Systems requiring cross-border identification must conform to the architecture and standards defined in the **eIDAS 2.0 Regulation** and the associated **Architecture and Reference Framework (ARF)**. This includes: * **OpenID for Verifiable Presentations (OIDC4VP)** for requesting and receiving identity data from the EUDI Wallet. * **Verifiable Credentials (VC) Data Model 2.0** as the standard format for attributes presented by the EUDI Wallet. #### 3.3.3. User Authentication Methods * **Recommended:** **WebAuthn (Web Authentication) Level 3** (W3C Recommendation). The recommended mechanism for strong, phishing-resistant authentication. #### 3.3.4. Cross-Domain Identity Provisioning * **Recommended:** **SCIM (System for Cross-domain Identity Management) Protocol 2.0** (IETF RFCs 7643, 7644). The recommended standard for automating the exchange of user identity information. ### 3.4. Application and Service Communication This section defines the standards for how application components and services communicate with each other. #### 3.4.1. Synchronous APIs * **Protocols:** **HTTP/2** (IETF RFC 9113) and **HTTP/3** (IETF RFC 9114). * **Architectural Style:** **REST (Representational State Transfer)** is the primary architectural style for building web APIs. * **API Specification:** **OpenAPI Specification v3.1**. All RESTful APIs must be documented using a valid OpenAPI 3.1 definition. * **Supported:** **GraphQL Specification** (October 2021 or later). For use cases involving complex data queries. #### 3.4.2. Asynchronous APIs - **API Specification:** **AsyncAPI Specification v3.0**. All event-driven services must be documented using an AsyncAPI definition. - **Messaging Protocols:** * **Recommended:** **AMQP (Advanced Message Queuing Protocol) 1.0** (ISO/IEC 19464:2014). * **Supported:** **MQTT (Message Queuing Telemetry Transport) v5.0** (OASIS Standard). #### 3.4.3. Secure File Transfer - **Recommended:** **SFTP (SSH File Transfer Protocol)** (as defined in IETF RFC 4250 series). The use of unencrypted FTP (IETF RFC 959) is strictly forbidden. ### 3.5. Cloud and Containerization These standards ensure portability and operational efficiency in modern cloud environments. #### 3.5.1. Container Specifications - **Recommended:** **OCI (Open Container Initiative) Image Specification v1.1** and **Runtime Specification v1.2**. These standards ensure that container images and runtimes are interoperable. #### 3.5.2. Container Orchestration and Management - **Architectural Pattern:** Systems must be designed for management by a **declarative container orchestration engine**. While no single specification exists for orchestration, solutions must expose a declarative API for defining application state, deployment, scaling, and networking. This ensures alignment with Infrastructure as Code principles. #### 3.5.3. Software Supply Chain Security - **Recommended:** All applications must be accompanied by an **SBOM (Software Bill of Materials)**. - **Formats:** * **SPDX (Software Package Data Exchange) 3.0** (ISO/IEC 5962:2021). * **CycloneDX 1.5**. ## Chapter 4: Syntactic Interoperability Standards ### 4.1. Introduction to Syntactic and Semantic Standards While Chapter 3 defined the protocols for communication, this chapter specifies the "language" of that communication. Syntactic interoperability ensures that systems can accurately parse the structure of exchanged data, while semantic interoperability ensures they can understand its meaning. This chapter provides the recommended standards for data formats, schemas, and the vocabularies needed to achieve both. Adherence to these standards is fundamental to creating data that is not only machine-readable but also machine-understandable across organisational and national boundaries. ### 4.2. General Data Formats and Encoding These standards apply to the general encoding and structuring of data for most use cases, particularly for API-based exchanges. #### 4.2.1. Primary Data Formats * **Recommended:** **JSON (JavaScript Object Notation)** (as defined in IETF RFC 8259 and ECMA-404). JSON is the default format for data serialization in synchronous and asynchronous APIs due to its simplicity, broad support, and human-readability. * **Supported:** **XML (Extensible Markup Language) 1.0** (W3C Recommendation). XML remains supported for document-centric exchanges, complex data structures requiring its specific features (e.g., mixed content), and for maintaining backward compatibility with legacy systems. #### 4.2.2. Schema and Validation * **Recommended:** **JSON Schema** (Draft 2020-12 or later). All JSON data structures exchanged via APIs should be accompanied by a JSON Schema definition to enable validation, documentation, and automated processing. * **Supported:** **XML Schema (XSD) 1.1** (W3C Recommendation). Required for validating the structure and content of all XML-based data exchanges. #### 4.2.3. Character Encoding * **Mandatory:** **UTF-8** (as defined in IETF RFC 3629). To ensure proper representation of all characters across all European languages, UTF-8 is the mandatory character encoding for all data exchanges and text-based documents. #### 4.2.4. High-Performance Data Formats * **Supported:** For internal, high-volume data streaming or storage where performance is critical, the following binary formats are supported: * **Apache Avro 1.11** * **Protocol Buffers (Proto3 language version)** ### 4.3. Document and Content Formats This section defines the standards for user-facing documents and web content. #### 4.3.1. Editable Documents * **Recommended:** **ODF (Open Document Format for Office Applications) v1.3** (OASIS Standard and ISO/IEC 26300). ODF is the default standard for all editable office documents, including text documents, spreadsheets, and presentations. #### 4.3.2. Non-Editable and Archival Documents * **Recommended:** **PDF (Portable Document Format) 2.0** (ISO 32000-2:2020). For distributing documents intended for viewing and printing. * **Mandatory for Archiving:** **PDF/A-4** (ISO 19005-4:2020). For long-term preservation of electronic documents, the PDF/A-4 profile must be used to ensure self-contained, device-independent renderability over time. #### 4.3.3. Web Content * **Recommended:** **HTML5** (W3C Recommendation). The standard for structuring all web content. * **Recommended:** **CSS3 (Cascading Style Sheets Level 3)**. The standard for describing the presentation of web content. All web services must also comply with the **Web Content Accessibility Guidelines (WCAG) 2.1** or later at level AA. #### 4.3.4. Technical Documentation * **Recommended:** **Markdown** (specifically the **CommonMark Spec v0.30** or later). For creating lightweight technical and project documentation. ### 4.4. Semantic Interoperability: Ensuring Shared Meaning Syntactic interoperability is insufficient on its own. Systems must also share a common understanding of the data they exchange. This is achieved through the use of common vocabularies and data models. #### 4.4.1. Core Vocabularies * **Mandatory:** Public administrations must use the **European Core Vocabularies** where applicable. These are simplified, context-neutral data models for representing fundamental concepts. Key vocabularies include: * **Core Person, Core Business, Core Location, Core Criterion and Core Evidence ([CCCEV](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/e-government-core-vocabularies/releases))**. * These vocabularies are maintained by the European Commission through the **[SEMIC](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre) (Semantic Interoperability Community)** and are available on the Joinup platform. #### 4.4.2. Data Cataloguing * **Mandatory:** All public data portals and catalogues must expose their metadata using the **DCAT Application Profile for data portals in Europe (DCAT-AP) v3.0** or later. This ensures that datasets are discoverable across the Union. #### 4.4.3. Knowledge Representation and Linked Data * **Recommended:** For representing complex relationships and building knowledge graphs, the following W3C standards are recommended: * **RDF 1.1 (Resource Description Framework)** * **RDFS 1.1 (RDF Schema)** * **OWL 2 (Web Ontology Language)** * **SPARQL 1.1 (SPARQL Protocol and RDF Query Language)** * **Supported:** **JSON-LD 1.1**. For embedding linked data semantics within a standard JSON format, facilitating easier adoption. ### 4.5. Domain-Specific Standards This section lists key domain-specific standards that are mandatory or recommended for use within their respective areas. #### 4.5.1. Geospatial Information * **Recommended:** **OGC API Standards**. For all new geospatial services, the modern OGC API suite is recommended over legacy standards (e.g., WMS, WFS). This suite includes: * **OGC API - Features** * **OGC API - Maps** * **Data Formats:** * **Recommended:** **GeoJSON** (IETF RFC 7946). The default format for representing simple geographic features. * **Supported:** **GML (Geography Markup Language)** (ISO 19136:2020). Supported for complex geospatial data and backward compatibility. #### 4.5.2. e-Invoicing * **Mandatory:** All electronic invoices must be compliant with the **European standard on e-invoicing (EN 16931-1:2017)**. #### 4.5.3. Digital Signatures * **Mandatory:** Electronic signatures and seals must conform to the standards laid out in the eIDAS Regulation. The technical specifications for signature formats are maintained by ETSI: * **PAdES (PDF Advanced Electronic Signatures)** * **XAdES (XML Advanced Electronic Signatures)** * **CAdES (CMS Advanced Electronic Signatures)** ## Chapter 5: Interoperability in Emerging Technologies ### 5.1. Introduction to Future-Proofing Public Services The rapid pace of technological change requires a proactive approach to standardization. This chapter provides guidance on key emerging technologies that are poised to significantly impact the public sector: Artificial Intelligence (AI), Distributed Ledger Technology (DLT), and the advent of quantum computing. The goal is not to mandate specific implementations but to establish a common European approach to their adoption. This ensures that as these technologies mature, they are integrated into the public service landscape in a manner that is secure, interoperable, and fully compliant with the Union's legal and ethical frameworks. ### 5.2. Artificial Intelligence and Machine Learning (AI/ML) The use of AI/ML systems in public administration offers immense potential for improving efficiency, decision-making, and service personalisation. However, it also introduces risks related to bias, transparency, and accountability. Interoperability in this domain extends beyond data formats to include models, metadata, and operational practices. #### 5.2.1. AI Model Interoperability * **Recommended:** **ONNX (Open Neural Network Exchange)**. To avoid vendor lock-in within specific AI development frameworks and to facilitate the deployment of models across different hardware and software platforms, the use of the ONNX format for exchanging trained models is recommended. * **Supported:** **PMML (Predictive Model Markup Language)**. For classical statistical and data mining models, PMML is a supported standard for model representation. #### 5.2.2. AI Transparency and Regulatory Compliance * **Mandatory:** All AI systems deployed by public administrations must be designed and operated in full compliance with the **AI Act**. This includes, but is not limited to: * **Risk Management:** Implementing a continuous risk management system throughout the AI system's lifecycle. * **Data Governance:** Ensuring that training, validation, and testing datasets are relevant, representative, and, to the best extent possible, free of errors and complete. * **Technical Documentation:** Maintaining comprehensive technical documentation that demonstrates the system's compliance before it is placed on the market or put into service. * **Human Oversight:** Designing systems to be effectively overseen by humans. #### 5.2.3. Explainability and Metadata * **Architectural Pattern:** AI systems, particularly those classified as high-risk under the AI Act, must be designed for **explainability**. While no single standard exists, systems should implement techniques that allow for the generation of human-understandable explanations of their decisions. * **Recommended:** **AI/ML Model Cards**. For transparency and governance, all deployed models should be accompanied by a "Model Card"—a standardized document that provides context and metadata about the model's intended use, performance characteristics, fairness evaluations, and ethical considerations. A common European template for Model Cards will be developed by the EITC. ### 5.3. Distributed Ledger Technology (DLT) and Blockchain DLT and blockchain technologies offer novel ways to create trusted, decentralised, and auditable records. Their application in the public sector should be targeted at specific use cases where these characteristics provide clear value over traditional centralised databases. #### 5.3.1. Alignment with Union-Level Infrastructure * **Recommended:** Where a use case for DLT is identified (e.g., for notarization, self-sovereign identity, or auditable supply chains), projects should prioritise alignment with and integration into the **European Blockchain Services Infrastructure (EBSI)**. EBSI provides a Union-wide, standards-based blockchain infrastructure that ensures cross-border interoperability. #### 5.3.2. Identity and Data Standards in DLT * **Mandatory:** When DLT is used for identity-related purposes, it must be fully compatible with the eIDAS 2.0 framework. Specifically, the issuance and verification of digital attributes must conform to the **Verifiable Credentials (VC) Data Model 2.0** and associated cryptographic standards. * **Recommended:** To ensure data interoperability, data recorded on a distributed ledger should, wherever possible, be structured according to the **Core Vocabularies** (see Chapter 4.4.1) and accompanied by appropriate metadata. ### 5.4. Post-Quantum Cryptography (PQC) The development of large-scale quantum computers poses a long-term existential threat to the security of currently deployed public-key cryptography (e.g., RSA, ECC), which underpins nearly all secure digital communication and signatures today. Public administrations must begin preparing for this transition now to protect long-term data confidentiality and the integrity of digital records. #### 5.4.1. Cryptographic Agility * **Architectural Mandate:** All new systems must be designed with **cryptographic agility**. This means that cryptographic algorithms and protocols are implemented in a modular way that allows them to be easily replaced or updated without requiring a complete system redesign. Hard-coding of specific cryptographic primitives is strictly forbidden. #### 5.4.2. Transition to Post-Quantum Standards * **Guidance:** Public administrations must closely monitor the post-quantum cryptography standardization process, particularly the standards selected by **NIST (National Institute of Standards and Technology, USA)** and their subsequent adoption by European and international standards bodies (e.g., ETSI, ISO/IEC). * **Roadmap Requirement:** All IT projects that handle sensitive data with a long-term confidentiality requirement (e.g., >10 years) must include a roadmap for migrating to PQC standards once they are formally approved and widely available in validated software libraries. This includes planning for hybrid cryptographic schemes (combining classical and post-quantum algorithms) as an interim step. This proactive stance on emerging technologies ensures that the European public sector can innovate responsibly, harnessing new capabilities while upholding its core commitments to security, interoperability, and the fundamental rights of its citizens. ## Chapter 6: Interoperability Profiles ### 6.1. Introduction to Interoperability Profiles To translate the architectural principles and technical standards of this framework into practical application, the EIF-TS provides a set of **Interoperability Profiles**. Each profile corresponds to a common use case or architectural scenario encountered in public service development. A profile is a coherent and limited selection of standards, patterns, and options, bundled together to ensure interoperability for a specific purpose. By adhering to a profile, project teams can accelerate development, reduce design complexity, and ensure that their solution is conformant with the EIF-TS by default. The following profiles are defined as a baseline. This list is not exhaustive and will be expanded in future versions of the EIF-TS as new common patterns emerge. Project teams must select the most relevant profile(s) for their system and may combine profiles where necessary (e.g., a service may conform to both the Secure RESTful API and the EUDI Wallet Integration profiles). ### 6.2. Profile P1: Base Public Web Service * **Objective:** To provide a standard, secure, accessible, and user-centric public website, portal, or informational web application. * **Architectural Patterns:** * API-Led (for content delivery). * Zero Trust Security. * **Key Enabling Standards:** * **Content:** HTML5, CSS3, WCAG 2.1 (Level AA). * **User Authentication:** WebAuthn (for services with login functionality). * **Documents:** PDF, ODF v1.3. * **Transport Security:** TLS 1.3, HTTP/2 or HTTP/3. * **Data Exchange (if applicable):** JSON, OpenAPI v3.1 for any backend APIs. ### 6.3. Profile P2: Secure RESTful API for Data Exchange * **Objective:** To define the default pattern for creating a new, secure, and well-documented API for data sharing between public administrations (A2A) or for exposing public data to third parties (A2B/A2C). * **Architectural Patterns:** * API-Led and Microservices Architecture. * Zero Trust Security. * **Key Enabling Standards:** * **API Specification:** OpenAPI Specification v3.1. * **Data Format:** JSON with JSON Schema. * **Authorization:** OAuth 2.1 (for delegated access). * **Authentication:** OpenID Connect 1.0 (for identifying client applications or end-users). * **Transport Security:** TLS 1.3. ### 6.4. Profile P3: Asynchronous Notification Service * **Objective:** To provide a standard pattern for services that need to send decoupled, real-time notifications or process tasks asynchronously, such as updating a citizen on their application status or synchronising data across multiple government databases. * **Architectural Patterns:** * Event-Driven Architecture (EDA). * **Key Enabling Standards:** * **API Specification:** AsyncAPI v3.0. * **Messaging Protocol:** AMQP 1.0 (for guaranteed delivery) or MQTT v5.0 (for lightweight use cases). * **Data Format:** JSON with JSON Schema. * **Transport Security:** TLS 1.3. ### 6.5. Profile P4: EUDI Wallet Integration * **Objective:** To provide a specific profile for public services that need to authenticate citizens or request certified attributes (e.g., diplomas, permits) from their European Digital Identity (EUDI) Wallet. * **Architectural Patterns:** * API-Led Architecture. * Zero Trust Security. * **Key Enabling Standards:** * **Framework:** eIDAS 2.0 Architecture and Reference Framework (ARF). * **Data Presentation:** OpenID for Verifiable Presentations (OIDC4VP). * **Attribute Format:** Verifiable Credentials (VC) Data Model 2.0. * **Transport Security:** TLS 1.3. ### 6.6. Profile P5: Geospatial Data Service * **Objective:** To define the standard way of publishing and consuming dynamic, interoperable geospatial data and map services, replacing legacy approaches. * **Architectural Patterns:** * API-Led Architecture. * **Key Enabling Standards:** * **Service Interfaces:** OGC API suite (Features, Maps, etc.). * **Data Format:** GeoJSON, with support for GML for complex features. * **API Specification:** OpenAPI v3.1. * **Transport Security:** TLS 1.3. ### 6.7. Profile P6: Cloud-Native Application Deployment * **Objective:** To define the standard for packaging, deploying, and operating scalable and resilient applications in a modern, cloud-agnostic environment. * **Architectural Patterns:** * Cloud-Native Architecture. * **Key Enabling Standards:** * **Containerisation:** OCI Image and Runtime Specifications. * **Orchestration:** Declarative management via an API-driven orchestration engine. * **Software Supply Chain:** SBOM in SPDX or CycloneDX format. * **Infrastructure Definition:** Adherence to Infrastructure as Code (IaC) principles. ### 6.8. Profile P7: AI-Enhanced Service * **Objective:** To provide a framework for integrating a machine learning model into a digital service in a transparent, secure, and compliant manner. * **Architectural Patterns:** * API-Led (for exposing model predictions). * Zero Trust Security. * **Key Enabling Standards:** * **Model Exchange:** ONNX. * **Service Interface:** RESTful API with OpenAPI v3.1. * **Compliance:** Adherence to the risk management and transparency requirements of the **AI Act**. * **Documentation:** Provision of a "Model Card" detailing model characteristics and performance. * **Deployment:** Conformance with Profile P6 (Cloud-Native Application Deployment). ## Chapter 7: Governance and Lifecycle ### 7.1. Introduction to Governance A technical specification of this nature cannot be static. Technology evolves, new standards emerge, and the needs of public administrations change. To ensure the EIF-TS remains a relevant, effective, and trusted instrument, a clear and transparent governance model is essential. This chapter outlines the structures, processes, and responsibilities for managing the lifecycle of the EIF-TS, from proposing changes to ensuring its continuous improvement. The governance model is founded on the principles of openness, community participation, and consensus-driven decision-making, reflecting the collaborative spirit of the Union. ### 7.2. Governance Bodies and Responsibilities #### 7.2.1. The European Interoperability Technical Committee (EITC) * **Mandate:** The EITC is hereby established as the primary governance body for the EIF-TS. It is responsible for overseeing the maintenance, evolution, and promotion of this specification. * **Composition:** The EITC will be co-chaired by representatives from the European Commission's Directorate-General for Informatics (DG DIGIT) and Directorate-General for Communications Networks, Content and Technology (DG CNECT). Its members will include nominated technical experts from Member State public administrations, as well as observers from relevant standards development organisations (SDOs) and the open-source community. * **Responsibilities:** * Reviewing and approving all changes, updates, and new versions of the EIF-TS. * Evaluating proposals for new standards and architectural patterns. * Maintaining the official documentation and reference materials related to the EIF-TS. * Promoting the adoption and correct implementation of the EIF-TS across the Union. * Resolving ambiguities and publishing official interpretations or clarifications as needed. #### 7.2.2. The Joinup Platform * **Role:** The **Joinup platform** will serve as the official public forum and collaboration space for the EIF-TS. It will host: * The official, versioned releases of this specification. * Public discussions, proposals for change, and feedback collection. * A repository of supporting materials, including reference implementations, best practices, and case studies. * Announcements and proceedings of the EITC. ### 7.3. Lifecycle and Change Management Process The EIF-TS is a living document subject to a managed lifecycle to ensure its stability and relevance. #### 7.3.1. Review Cycle * The EIF-TS will undergo a formal review on an **annual basis**. This review will assess the continued relevance of existing standards, consider the maturity of emerging technologies, and incorporate feedback from the implementation community. * Minor updates (clarifications, errata) may be released on a more frequent basis as needed, while major revisions will follow the annual cycle. #### 7.3.2. Change Proposal Process 1. **Submission:** Any stakeholder (including Member State administrations, EU institutions, industry, academia, and individual experts) may submit a proposal for change via the Joinup platform. Proposals must be well-justified and include a clear description of the proposed change, its rationale, and its potential impact. 2. **Public Comment:** All submitted proposals will be open for a public comment period to gather community feedback. 3. **Assessment:** The EITC will conduct a formal assessment of the proposal. This assessment will use the **Common Assessment Method for Standards and Specifications ([CAMSS](https://interoperable-europe.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss))** to evaluate the maturity, market support, and openness of any proposed new standard. The proposal's alignment with the Core Principles (Chapter 1) and Architectural Patterns (Chapter 2) of the EIF-TS will be a primary evaluation criterion. 4. **Decision:** Based on the assessment and community feedback, the EITC will make a decision to accept, reject, or request modification of the proposal. All decisions and their justifications will be made public. 5. **Integration:** Accepted proposals will be integrated into the next planned release of the EIF-TS. ### 7.4. Compliance and Assessment To support public administrations in implementing this framework, a set of tools and guidelines will be developed and maintained. * **EIF-TS Compliance Toolkit:** The EITC will provide a self-assessment toolkit, including checklists and scoring mechanisms, to help project teams evaluate their alignment with the EIF-TS. This will enable a consistent approach to measuring compliance and identifying areas for improvement. * **Reference Implementations:** To demonstrate the practical application of the interoperability profiles, the Commission will support the development of open-source reference implementations for key use cases. These will serve as accelerators and learning tools for the community. ### 7.5. Next Steps and Future Work The publication of this version 1.0 of the EIF-TS marks the beginning of a continuous, collaborative effort. The immediate next steps are: 1. **Adoption and Dissemination:** The European Commission will formally adopt the EIF-TS for its own systems and will work with Member States to promote its adoption at the national level, encouraging the alignment of National Interoperability Frameworks. 2. **Establishment of the EITC:** The formal establishment of the EITC and the nomination of its members will be completed within six months of this document's publication. 3. **Community Building:** A dedicated community of practice will be launched on the Joinup platform to foster knowledge sharing, collaboration, and the co-creation of supporting assets. The future of digital public services in Europe depends on our collective ability to build on a common, secure, and interoperable foundation. This framework provides that foundation, and its success will be measured by the active participation of all stakeholders in its implementation and evolution. ## Notes This work is baed on the [2015 French RGI](https://www.numerique.gouv.fr/offre-accompagnement/reference-interoperabilite-rgi/). (See also this [Wikipedia entry](https://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentiel_g%C3%A9n%C3%A9ral_d%27interop%C3%A9rabilit%C3%A9)). However, this draft EIF-TS represents a significant evolution, not just an update. Here are the most critical changes: 1. **Strategic Repositioning (EU vs. French National):** * **Scope:** The document is explicitly European, targeting cross-border interoperability and aligning with EU-level legislation (Digital Decade, AI Act, eIDAS 2.0). The RGI was a national French framework. * **Tone and Authority:** It speaks with the authority of the European Commission (DG CNECT/DIGIT), positioning it as a foundational document for the Digital Single Market. 2. **Architecture-First, Not Standards-First:** * **The biggest shift:** The 2015 RGI was primarily a catalogue of standards. The EIF-TS introduces **Chapter 2: Modern Architectural Patterns** as a mandatory preceding step. It forces projects to think about *how* they build (API-led, EDA, Zero Trust) before they think about *what* they build with. This is a massive leap in maturity. Note that this is also the most debatable part. Remember this is just a draft! 3. **Embracing the Modern Technology Stack:** * **Cloud-Native is Default:** The RGI was written in a pre-container world. The EIF-TS fully embraces cloud-native principles, making **containers (OCI), declarative orchestration, and Infrastructure as Code (IaC)** core tenets. * **APIs are Central:** The RGI mentioned SOAP and had a nascent view of web services. The EIF-TS makes **REST/OpenAPI** and **AsyncAPI** central to everything, reflecting the API economy. * **Modern Identity:** The RGI's identity standards (SAML) are now relegated to "supported/legacy." The EIF-TS rightfully puts **OIDC, OAuth 2.1, and the EUDI Wallet (Verifiable Credentials)** at the forefront. 4. **Future-Proofing and Emerging Technologies (Chapter 5):** * This entire chapter is new and crucial. The RGI had no concept of providing guidance on **AI/ML (ONNX, AI Act), DLT (EBSI), or Post-Quantum Cryptography (PQC)**. This positions the EIF-TS as a forward-looking, strategic document, not just a reactive one. 5. **Practical, Use-Case Driven Guidance (Chapter 6):** * The RGI's "profiles" were high-level groupings. The EIF-TS profiles are much more concrete **"recipes"** that combine specific architectural patterns and standards for common problems (e.g., "Build a secure API," "Integrate with the EUDI Wallet"). This makes the framework much more actionable for development teams. 6. **Strengthened Governance Model:** * The EIF-TS establishes a formal **European Interoperability Technical Committee (EITC)** with a clear mandate and a transparent, community-driven change process via the Joinup platform. This is a more robust and inclusive governance model than the one described for the RGI. 7. **Updated and Curated Standards List:** * **Dropped:** Obsolete standards from the RGI like FTPS, PeSIT, H.320, XHTML have been removed. * **Kept & Updated:** Core standards that are still relevant have been kept and updated to their latest versions (e.g., PDF -> PDF/A-4, TLS -> TLS 1.3, IPv4 -> IPv6 as default). * **Added:** A huge number of modern, essential standards are new additions (e.g., OIDC, WebAuthn, OpenAPI, AsyncAPI, OCI, ONNX, GeoJSON, Verifiable Credentials, etc.).