1. Once-Only Technical System High Level Architecture - Snapshot Q3

Purpose of the document

The following table summarises the objectives, target audience and main outputs of this document:

Acronyms

References

1. Introduction

1.1. Once-Only Technical System

Article 14 of the Single Digital Gateway Regulation [REF30] states that the Commission, in cooperation with the Member States, shall establish a technical system for the cross-border automated exchange of evidences between competent authorities in different Member States. The draft "once-only" Implementing Act [REF38] further sets out the technical and operational specifications of the technical system necessary for the implementation of this Article. (References to this draft will be replaced by the references to the IR once it is adopted by the Commission and published in the Official Journal).

This document complements the Implementing Act by providing a high-level architecture. This high level architecture is complemented by, and serves as an introduction to, further technical and operational design documents. References to current versions of this documentation are provided in this document. Together, these documents and the interface documentation they provide deliver the interoperability necessary to support the implementation and interconnection of the distributed components that constitute the Once-Only Technical System (OOTS). 

1.2. Context

Initial preparatory work for the entry into force of the Once-Only Technical System, which is set to be in place and ready for use by 12 December 2023 was organized into a number of Work Packages, operating under the SDG Coordination Group.

As of 2022, work support OOTS is done in sub-groups. Sub-groups are defined in Article 19 of the OOTS Implementing Act [REF38].  These Technical Design Documents relate to the sub-group defined in paragraph 1 (c) of that article, which is responsible for "review, maintenance and interpretation of the technical design documents"

The Once-Only technical system serves primarily as an integration mechanism for existing systems in Member States and is therefore primarily concerned with establishing interoperability by providing interface documentation.  Interoperability is defined in the European Interoperability Framework (EIF, [REF19]). 

1.3. Input

This document is based on the following main inputs:

• Single Digital Gateway Regulation, in particular Art 14 [REF30];
• OOTS Implementing Act [REF38].

Other inputs include:

• Deliverables and other input from the TOOP Large Scale Pilot [REF34];
• Deliverables and information from the DE4A Large Scale Pilot [REF7];
• The “OOP Blueprint” [REF1] created by the preparatory action on "once-only". That action, which was started in 2019, intends to pave the way for the creation of a dedicated ‘Once-Only Principle' (OOP) Building Block and the identification of potential new building blocks supporting cross-border interoperability;
• Input from Member State representatives in the SDG Coordination Group, provided during its periodic SDG plenary meetings;
• Input from Member State experts, provided during bilateral meetings scheduled with their representatives in the SDG Coordination Group, but also involving a broader range of experts;
• Input from Member State experts participating in the meetings and discussion item section of WP7, "Technical Design";  WP2, "User Centricity"; WP4, "Semantics",  and WP6, "Functionality";
• Input from policy and subject matter experts in the Commission and from other Commission actions, in particular the ISA² and Interoperable Europe actions and the Building Blocks at DIGIT and the relevant units at DG GROW and DG CNECT.

1.4. Scope

This document covers the Once-Only Technical System specified in Article 14 of the SDG Regulation [REF30] and the draft Implementing Act [REF38].

This system will come as an addition to several existing systems for cooperation between Member States mentioned in recital (50) of the regulation, which are used to exchange evidence for exchanges that are in the scope of the SDG Regulation. 

Other types of evidence handling, not in the scope of this document, include:

• Once-Only functionality that does not involve any cross-border border exchange;
• Cross-border exchange involving private sector sources;
• Evidences directly uploaded by the user;
• Once-Only functionality that uses different mechanisms for the exchange of evidences, as stated in Art 14.10.

Requirements of the SDG Regulation other than functionality covered by Article 14 are also out of scope.

1.5. Extensibility

While Article 14 of the SDG Regulation [REF30] and the Implementing Act [REF38] set a clear functional scope, the intended applicability of the OOP Technical System is broader. The system, or selected subsets of it, support and enable other data sharing requirements. In particular, the system is intended to not be limited to the procedures described in Article 14.1 but to also support other electronic procedures.

A key consideration is to make sure that additional functionality, if needed in the future, can be added in an incremental way to avoid a major redesign of the initial system.  Incremental extensions in the future are made easier by defining the OOP system, as much as possible, using profiled subsets of more comprehensive open standards. This will allow functionality to be added relatively easily by extending the profiled subsets beyond the requirements in Article 14 of the SDG Regulation. This approach of using profiled subsets of standards was used successfully in the eDelivery Building Block, which has been extended in response to new needs without disrupting existing users and deployments.

A future version of the OOTS may also incorporate, at design level, other implementation technologies to implement existing elements, or add additional optional elements.  

1.6 Structure of this document

The remainder of this document is structured as follows:

• Section 2, Requirements: gives an overview of the requirements on which the architecture is based.
• Section 3, Once-Only Technical System Architecture: provides a high level overview of Business Layer and Application Layer views. It partitions the elements in the architecture in four groups, which are discussed in the four next sections;
• Section 4, Evidence Requester Side Architecture Elements: covers Requester-side systems;
• Section 5, Evidence Providing Side Architecture Elements: covers Provider-side elements;
• Section 6, Once-Only Common Services that support the system;
• Section 7, Evidence Exchange and eDelivery: explains evidence exchange protocol supported by the eDelivery Building Block;
• Section 8, Identification and Representation: covers identification of natural and legal persons as well as representation;
• Section 9, System Operation: covers general operational constraints for the technical system;
• Section 10, Sample Once-Only Flows: describes in some detail a sample flow involving the Once-Only Technical System.

2. Requirements

The High Level Architecture is closely aligned with the activities and outputs of the User Centricity Work Package. That Work Package is in the process of defining a set of Functional Requirements that the Once-Only Technical System must support [REF37].

The following table complements these functional requirements by providing a more general overview of the key architectural requirements that the Once-Only Technical System addresses. The table classifies these requirements using the ISO 25010 quality attributes framework [REF36]. It also provides the source, in most cases the relevant section of the SDG Regulation (label "SDG.*"), the Implementing Act (label "IA.*"), and/or the applicable principle from the European Interoperability Framework (label "EIF.*") [REF19]. To support traceability, the table indicates the architectural element (or elements) in which each requirement is addressed.     

3. Once-Only Technical System Architecture

3.1. Context

The Single Digital Gateway Regulation [REF30] aims to make it easier for a user to initiate and execute, subject to specified constraints, a set of procedures online where:

• the user is using an Online Procedure Portal of a public administration in a Member State;
• the procedure requires evidence from a different Member State than the Member State hosting the Online Procedure Portal.

While carrying out a cross-border online procedure, evidence relating to a citizen (of the Union), a natural person (residing in a Member State)  or a legal  person (having its registered office in a Member State) may be required. The Once-Only Technical System allows the governmental Portal to request, following the explicit request of the user (unless exemptions apply), the exchange of evidences from one or several competent authorities in (a) different Member State(s), for use in the context of the procedure. This means that this system aims at enabling cross-border data-sharing between competent authorities at all administrative levels (local, regional and national).

Note that:

• Under ECJ case law competent authorities can also be non-governmental entities with a formal task in the public remit. 
• The competent authority or intermediary platform that issues the evidence acts, in terms commonly used in other contexts (including the former TOOP large scale pilot [REF34]), as a Data Provider. The competent authority or intermediary platform that requests the provided evidence acts as a Data Consumer.

This document provides a high-level architecture for the Once-Only Technical System. Its aim is to link the SDG Regulation [REF30] and Implementing Act [REF38] to the more detailed technical design documents and to provide a summary overview. 

3.2. Approach

The OOP Technical System establishes a general purpose data exchange ecosystem for the public sector in Europe. The system enables trusted cross-border data sharing between competent authorities in a distributed environment involving many evidence providers and many evidence requesters. 

The Once-Only Technical System is not a single monolithic system. Instead, it is a distributed collection of systems that, once interacting with one another, form a Once-Only technical “ecosystem”. Rather than assuming a shared, single, central information system, the architecture takes a decentralized approach based on integration and interconnection of independent systems. Most of the systems that will be part of the Once-Only Technical System are independently operated by Member States, and many of them are likely to be (evolutions of) existing systems that are already in use today, rather than new systems designed specifically for Once-Only in the context of the SDG Regulation.

To allow the interconnection of existing systems in use in Member States, the architecture uses a loosely coupled interoperability layer based on the concept of common reusable “Building Blocks”. Building Blocks provide agreed, common interfaces. They are designed to minimise the impact on existing systems in Member States and to maximise opportunities for reuse. The architecture includes interoperability-enabling elements provided by existing Building Blocks developed under the former Connecting Europe Facility (CEF) such as eID and eDelivery [REF3] and adds additional Once-Only common services to provide comprehensive support for Once-Only. The interfaces may be implemented in multiple independent software implementations or services, including software products or services from third party solution providers.  

3.3. Overview

Figure 1 provides a High Level view of the Once-Only Technical System.[1] The system as shown includes two processes. On the side of the Evidence Requester, there is a “Once-Only Evidence Exchange” business process that establishes a transition between two business events, associated to a cross-border administrative procedure:

1. A “Cross-Border Evidence Required” input event that indicates that (an action in) a procedure requires one or more evidences to be retrieved from one or more other Member States (this will most likely be based on information supplied by the user). 
2. An “Exchange Completed” output event that occurs when, in case of success, the required evidence(s) has/have been exchanged, where “exchange” implies not just the transmission of the evidence, but also the request of the user and the acceptance for use in the procedure. Note that the exchange may also be unsuccessful, if no evidence was available or the user decided not to use it in the procedure. 

On the side of the Evidence Provider, there is a supporting business process called "Evidence Preview". 

Figure 1 High Level View of the Once-Only Technical System

Both of these events relate to the competent authority or intermediary platform that requests the evidence(s). They are connected by the business process that involves interactions with:

• the user;
• the Data Service of the competent authority or intermediary platform that provides the evidence, acting as Evidence Provider;
• Once-Only common services that support the operational uses of the Once-Only Technical System.

The flow of the business process follows the steps described in Article 14(3) of the SDG Regulation [REF30].

As Article 14(7) of the SDG Regulation and Article 12 of the Implementing Act explain, an evidence request is issued by a competent authority or intermediary platform but is subject to an explicit request given by the user, unless otherwise provided under Union or national law. It therefore relies on authentication of the user. This is provided by the “Establish Identity” business function that is served by an “Electronic Identification Service”. This service may be provided by the eIDAS Node component from the eID Building Block [REF17] or by other components (not shown in the diagram), such as a notified electronic identification service of the Member State in which the requesting authority or intermediary platform is based. Since identification is typically a general requirement for electronic procedures and not only for evidence exchange, it is not modelled as a step in the exchange business process but as a business function that serves it.

The “Once-Only evidence exchange” process consists of the following steps, all initiated from an Online Procedure Portal (see section 4.2):

1. "Express Request" is a step in which the user is asked to express explicitly whether he or she wants to use the Once-Only Technical System. 
2. “Lookup and Select Evidence Type” is an optional step in which an “Evidence Type Lookup Service” is used to determine the type of evidence to be retrieved. This service is implemented in an Evidence Broker component (see section 6.2). 
3. “Lookup and Select Evidence Provider” is a step in which a “Data Service Lookup Service” is used to determine the competent authority or intermediary platform to which the evidence request is made. This service is provided by a Data Service Directory component (see section 6.3).
4. “Lookup and Request Evidence” is a step in which a request for available evidences is made to a “Data Service” (see section 5.2) using eDelivery messaging. This service is provided by a “Base Registry” component owned by a competent authority or intermediary platform that is an “Evidence Provider”. If any evidences may be available from the contacted Data Services, the response will include hyperlinks that link to a separate "Evidence Preview Service" offered by (or on behalf of) the Evidence Provider. Note that offering the link is no firm indication that evidences are available for the user as this may depend on the outcome of (re)authentication in the preview space.  
5. "Select for Preview" is a step in which the user selects one or more available preview links for consideration. At this stage, the user will be provided the option to follow the hyperlinks to preview and decide on the use of the evidence, and return to the Online Procedure Portal. In parallel, any confirmed pieces of evidences are returned to the Portal using secure eDelivery  messaging.  
6. After returning from the Preview Space, the “Complete Exchange” is a step in which the user continues the procedure.

Of these six steps, all but the first and last involve interaction between IT systems in different Member States. The Once-Only Technical System is based on detailed technical design documentation that provide interoperability between these systems. The functionality provided by this business process may be assigned to a separate component ("Intermediary Platform"), rather than being provided by the Oneline Procedure Portal. For expository reasons this variation is omitted from text and diagrams.

The "Evidence Preview" process consists of the following steps, triggered by the combined actions of the Data Service providing a preview link and the user following this link:

1. "Re-authenticate" is an optional step in which the user is asked to re-authenticate as described in article 16 (1) of the implementing regulation [REF38]. This may include a dialog with the user in which she can provide additional attributes.
2. "Preview and select" is a step in which the user is given the opportunity to preview any pieces of evidence matching the request and her (re)established identity.
3. "Return" is a step in which the user is given the opportunity to return to the "Once-Only Evidence Exchange" process on the side of the Evidence Requester.  

This business process may be provided by a separate component, also called "Intermediary Platform" that may be shared among multiple Evidence Providers. For expository reasons this variation is omitted from text and diagrams.

The three services “Evidence Type Lookup Service”, “Data Service Lookup Service” and “Semantic Repository Service” together comprise a group of Once-Only common services. These platforms do not handle requests for evidences and their issuance directly but provides supporting services. 

Section 4 will discuss the architectural elements relating to the competent authority or intermediary platform that requests the evidence. Section 5 will do the same for the evidence-issuing competent authority or intermediary platform. Section 6 discusses the Once-Only common services. Section 7 and 8 cover eDelivery, evidence change and identification and authentication in the Once-Only Technical System.

3.4. Core and Extension Architectural Elements

The following elements are core elements as they are used for all "once-only" exchanges:

• Online Procedure Portal;
• Data Service;
• Data Service Directory;
• eDelivery Access Points.
• Preview Space.

Other elements of the architecture are extension elements, as their functionality is not always needed. For example:

• The user may authenticate to the Online Procedure Portal of a public administration in a Member State using a notified national eID of that Member State, thus obviating the need to use eIDAS nodes.
• In procedures in which Member States have agreed to all use the same evidence types, there is no need for Evidence Broker functionality to determine evidence types to select. In that case, an Online Procedure Portal can directly look up Data Services in the Data Service Directory without having to first look up a rule for a particular requirement.

Note that some functionality of Evidence Requesters and Evidence Providers may be provided by "Intermediary Platforms". 

3.5. Governance

Section VI of the Implementing Act [REF38] addresses some governance aspects of the Once-Only Technical System. It covers:

• The role of the Gateway Coordination Group established under the SDG regulation and its subgroups.
• Technical support.
• Cooperation with other governance structures.

3.6. Roles and Responsibilities

The Once-Only Technical System is a collection of interacting technical systems of the Member States and the Commission. According to Article 14(11) of the SDG Regulation, the Commission and each of the Member States shall be responsible for the development, availability, maintenance, supervision, monitoring and security management of their respective parts of the technical system.

Section VII of the  Implementing Act [REF38] covers responsibility for the maintenance and operation of the components of the OOTS.

4. Evidence Requester Architecture Elements

4.1. Introduction

The interaction in the Once-Only Technical System is an interaction between competent authorities. This section covers architecture elements involving systems of competent authorities that request evidences.

As an example, a university, or another public administration in the education domain, could provide an Online Procedure Portal to help candidates apply online for a tertiary education study financing. A prospective student that previously studied in a different Member State, or even in multiple different Member States, could use this portal to apply. Using the Once-Only Technical System, the candidate can provide the university or public administration with proof of any relevant existing qualifications he or she obtained from institutions in other Member State(s), and other relevant documentation such as information on social situation and level of income.

4.2. Online Procedure Portal

An Online Procedure Portal is an online system of a public administration in a Member State that allows users, including cross-border users from other Member States, to execute a procedure of the public administration. The Once-Only Technical System is concerned with the subset of functionality of an Online Procedure Portal that relates to the cross-border automated exchange of evidence between competent authorities in different Member States and application of the ‘once-only’ principle as defined in Article 14 of the SDG Regulation. This functionality is provided by the “Once-Only evidence exchange” business process as shown in Figure 1.

The functionality of an Online Procedure Portal can be considered along two dimensions, which relate to the two axes in Figure 2:

• Front end functionality versus back end functionality.  This is reflected in the vertical axis of the diagram.  Front end components can be implemented, for example, as a website that supports access using a Web browser or as a mobile application.  
• Different types of functionality. This is reflected in the horizontal axis of the diagram.  Seven components and related sets of functions are defined.

Figure 2 Online Procedure Portal Application View

Note that architectural, design and implementation details of an Online Procedure Portal implementation may differ between different portals. The diagram is non-normative. Its purpose is only to give a high level overview of services and components included in or used by portals.     

Together, the front end components and the back end components include functions to allow the user to execute the actions in the "Once-Only evidence exchange" business process, as well as any preceding actions that are preconditions:

• Identify himself/herself ("Establish Identity");
• Explicitly request to use the system for exchange of evidence ("Express Request");
• Select evidence types ("Lookup and Select Evidence Type");
• Select data services ("Lookup and Select Evidence Provider");
• Look up available pieces of evidence ("Lookup and Request Evidence");
• Consider some or all  pieces of evidences for preview and use in the procedure ("Select for Preview");
• Complete the process and continue back to the procedure ("Approve and Complete Exchange");

This architecture only specifies at a high level the interfaces provided by back-end components to front-end components. It does not constrain them at more detailed technical level because they are only used internally in Member State systems.  

In this version of the OOTS, following article 15 of the Implementing Act, it is assumed that the user executes the preview of and decision to use a piece of evidence using an Evidence Preview Service located in the Member State of the Evidence Provider. Any interaction with this service is therefore a temporary interruption of the business process of the Evidence Provider. The Online Procedure Portal needs to provide a Provider Redirect Handler function that:

• allows a user to choose to navigate to the Evidence Provider for preview and confirmation purposes. 
• provides a return address that the user can be directed back to in order to continue its  procedure.

The Once-Only Technical System is about exchange of "read-only" evidences. The user can decide to not use the evidence but cannot modify its content in any way. User confirmation to use evidence in the context of a particular procedure does not constitute an authorization to use the provided evidence in other contexts or for other purposes. 

Figure 2 classifies back end functions in three groups: 

• Procedure management and information systems integration. This is common functionality that is needed in an Online Procedure Portal that does not relate to Once-Only Technical System. It is mentioned for context. 
• Once-Only Common Services handler functions that interface to the Once-Only common services described in section 6. These functions include client interfaces to the Evidence Broker and the Data Service Directory.
• Evidence query service handler functions that control the exchange of evidence requests and correlated evidence responses (or error messages) from a Data Service using the functionality described in section 7.   

Article 9 of the Implementing Act [REF38] requires the Online Procedure Portal to explain the possibility to use the Once-Only Technical System and its features to users.  Article 10(1) requires involving the user in the selection of evidence types and data services. Article 11, user authentication, is addressed in section 8. Article 12 shows information that must be provided to the user before evidence is requested. 

An Online Procedure Portal Back-end needs to cover general electronic procedure functionality, such as procedure management functionality, to manage a user's session and flow through the procedure, and information system integration, which includes any permanent storage of procedure data and submitted evidences. These functionalities include:

• Procedure and session state management: at a particular point in time, multiple users may be interacting with the system and using the Once-Only Technical System. Any evidences that are returned in response are made available to the specific procedure end-user that issued the query for those evidences. In addition, user input to the procedure, and evidences retrieved to support it, may be provided over time, and possibly interrupted/resumed;
• Integration with information systems and/or databases and any required data or format transformation. This may involve transformation between different structured formats, or from structured (data-oriented) to unstructured (presentation-oriented) formats.

Since the Once-Only Common Services Handler and Evidence Query Service Handler relate to systems in different Member States, and to systems provided by the European Commission, their external interfaces are specified in design documentation of the Once-Only Technical System in order to achieve interoperability. Their internal interfaces to the front end components are not standardized as they are used within a Member State. 

The functionality for evidence exchange includes functionality to:

• Create evidence requests and submit them to the Online Procedure Portal Access Point for transmission to a Data Service;
• Receive responses, delivered to the Online Procedure Portal by the Online Procedure Portal eDelivery Access Point;
• Logging of evidence exchange information including date and time and unique identifiers of evidence request, evidence response, user, data service and evidence type. 

Article 13, content of evidence request, and Article 15, the response to evidence requests, are addressed in section 7.3.  

4.3. Online Procedure Portal Access Point

The Evidence Query Service Handler application component of an Online Procedure Portal uses an eDelivery Access Point to request the evidence from the evidence provider and receive the evidence in response. This may be a dedicated Access Point for that specific Portal, or a more general communication component that is also used by other portals and systems. By sharing an Access Point, competent authorities can reduce the cost and complexity of implementation. For further discussion and references, see section 7.2.

Since this Access Point is the entry point into the Once-Only Technical System, it is essential that the competent authority or intermediary platform on behalf of which the Access Point makes such a request has an appropriate legal basis to make such a request, such as Directive 2005/36/EC, 2006/123/EC, 2014/24/EU or 2014/25/EU or, for the procedures listed in Annex II of the SDG Regulation, other applicable Union or national law as stated in recital 45 of the SDG Regulation.  According to Article 35 of the Implementing Regulation, the Evidence Requester is responsible for lawfulness of the evidence request.

Member States are responsible for securing the evidence request as it is transmitted from an Online Procedure Portal to the Access Point, as required in Article 28 of the Implementing Act. For more information on requirements, see section 7.9.

4.4. eIDAS Node of Evidence Requesting Member State

To use the Once-Only system, the user needs to be identified and authenticated. If the user is has and uses an eID means issued by Evidence Requesting Member State, a notified eID scheme of the Member State may be used. If the user is from a different Member State and has an eID from that Member State, the eIDAS Nodes of the two Member States can be used for cross-border authentication. The mandatory attributes of the eIDAS minimum data set obtained from the user using either of these identifications methods are included in evidence requests to the Data Services. If the Unique Identifier is Member State specific, this attribute should not be included as it was issued for a specific context of the Online Procedure Portal. If eIDAS optional/sector specific attributes are received by the Evidence Requester, and it is in accordance with the national privacy policy, these attributes may also be included in the evidence request. The eID functionality will be accessed from the front-end part of the Online Procedure Portal and/or the Evidence Provider as it involves interaction with the user. For more on eIDAS nodes, see section 7.

5. Evidence Provider Architecture Elements

5.1. Introduction

The interaction in the Once-Only Technical System is an interaction between competent authorities.  A competent authority or intermediary platform that issues evidences in response to evidence requests provides a Data Service as specified in section 5.2. The transmission of requests and evidences uses an eDelivery Access Point as specified in section 5.3. This section covers architectural elements involving systems of competent authorities that issue evidences.

5.2. Data Service

Competent authorities in Member States operate Data Services to issue evidences, in response to requests from requesting competent authorities and users executing procedures in Online Procedure Portals. The legal base for this service is provided in article 15 of the Implementing Act.

For example, the Ministry of Education in one Member State may offer a service that provides evidences concerning diplomas, certificates or other proof of studies or courses obtained in that Member State that can be shared with other Member States through the OOP system.

A Data Service must implement a common “Evidence Query Service”. In support of this service, a Data Service includes functionality to:

• Receive evidence requests, delivered by an eDelivery Access Point, and interpret them. These requests are the input to the “Evidence Query Service”;
• Perform evidence request validation;
• Perform initial record matching, to determine which (if any) evidences in storage may relate relate to the user (see section 8.5);
• Apply, if requested, a transformation on the evidence, from a predefined set of transformations;
• Coordinate its processing with the Preview Space;
• Return evidence responses (including possibly errors) and submit them to an eDelivery Access Point for transmission to the requesting Online Procedure Portal.

This exchange of pieces of evidence (unless article 14.5 of the SDG regulation applies) is subject to user preview, re-authentication and approval. The user performs these actions using the Preview Space (see section 5.3 below). Therefore, in this case, two request-response loops are required:

• A first request-response loop in which the Data Service, if pieces of evidence may be available, returns hyperlink information that allows the Online Procedure Portal to direct the user to the Preview Space. 
• A second request-response loop, executed in the background and in parallel to the user's interaction with the preview space, that returns any selected pieces of evidences. 

The Data Service implements functions to coordinate the second request-response loop and the user's actions in the Preview Space and to make sure that:

• User identity attributes in the evidence request match the user's identity as established by authentication to the Preview Space.   
• Only pieces of evidence are made available to the user that are of the requested type and that relate to the identified data subject.
• Only pieces of evidence selected by the user for use in the procedure (if any) are included in the second loop evidence response.
• The interactive user activity relates to the same procedure execution on the side of the Evidence Requester.  

Re-authentication of the user in the Preview Space addresses the issue that the identity information obtained in the first loop and provided in the first evidence may not be sufficient for identity matching.  Note also that matching is not simple exact string matching but a matching that takes into the nature of the identity attribute data.  

A Data Service may respond to requests by providing pre-existing evidences or by creating or assembling evidences from data dynamically. Such assembling may involve operations such as selection, filtering or transformation. 

The generic format for evidence requests and responses is based on exchange data model design documentation based on open standards and technical specifications introduced in section 7.

A data service may not be directly connected to an information system. Instead, middleware or other integration solutions may be used. A data service may also connect to a national OOP layer, rather than integrate directly to an information system. This is not reflected in the following diagram.

Figure 3 Data Service Application View

5.3. Preview Space

In this version of the OOTS,  the Evidence Preview Service is offered by (or on behalf of) the evidence issuing competent authority or intermediary platform. The service may be an integral part of the Data Service or it may be a separate component, called Preview Space, as defined in article 15 of the IA. Subject to the conditions specified in that article, a single Preview Space component may offer an Evidence Preview Service to multiple Evidence Providers and their Data Services. 

The preview space provides user-interface related functions supporting the once-only user interaction. These allow the user to:

• Enter the space using a hyperlink that was communicated to the Online Procedure Portal using the response message in the first request-response loop.        
• Return to the Online Procedure Portal using a return address provided by the Online Procedure Portal.
• Authenticate himself or herself, if deemed necessary.
• Preview pieces of evidences of the selected evidence type.
• Decide whether or not to transmit any piece of evidence to the Online Procedure Portal so that it can be used in the procedure.

Mirroring the coordination functions of the Data Service, the Preview Space needs to make sure:

• All and only pieces of evidence matching an evidence request for the procedure the user is executing can be previewed and selected.
• Decisions by the user whether or not to use a piece of evidence are reflected in the evidence response by the Data Service.
• The identity attributes for the user in the evidence request match the attributes established by electronic identification of the user.  

Figure 4 Preview Space Application View

5.4. Data Service Access Point

The requests to a Data Service and the responses to those requests are exchanged securely and reliably using eDelivery. The Data Service must therefore also be accessible via an eDelivery Access Point. This may be a dedicated Access Point for that specific Data Service. It can also be a more general communication component that is also used by other applications. An Access Point may be shared by multiple competent authorities, to reduce the cost and complexity of implementation. For further discussion and references, see section 7.2.

Member States are responsible for securing the evidence as it is transmitted from a Data Service to the Access Point, as required in Article 29 of the Implementing Act. For more information on requirements, see section 7.9.

5.5. eIDAS Node of Evidence Issuing Member State

As mentioned in section 4.4, the eIDAS Node of the Member States from which evidences are requested may be used to authenticate the user to the online procedure. This is initiated via the eIDAS Node and Online Procedure Portal from which the evidence is requested. For more on eIDAS nodes, see section 6.3.

When the user follows a link to the Preview Space, he or she may be requested to re-authenticate. If the user is not authenticating using an eID from the Issuing Member State, he or she shall use the eIDAS Node system to authenticate using a notified eID from another Member State. 

6. Once-Only Common Services

6.1. Introduction

To support the exchange of evidences between Data Services and Online Procedure Portals, the Once-Only Technical System uses Once-Only supporting services. Article 4 of the draft Implementing Act [REF38] refers to these services as the Common Services. The Common Services do not process data about citizens or businesses. Instead they contain and serve operational data parameters that support the operation of the Once-Only technical system. The Common Services are:

• Evidence Broker (see section 6.2);
• Data Service Directory (see section 6.3);
• Semantic Repository (see section 6.4).

Each of these services will provide a life-cycle management interface (see section 6.5) to maintain the data it serves as this data is subject to change over time. The Once-Only Technical System follows a hybrid deployment model (see section 6.6).

6.2. Evidence Broker

The Once-Only Technical System supports situations in which an Online Procedure Portal, when performing an online procedure, requests an evidence from a data service in a different Member State. The evidence relates to a requirement to obtain information on a citizen or business or to prove that certain claims about the citizen or business are true. Its legal base is Article 6 of the Implementing Act.

If for a particular procedure, for a particular requirement, a harmonized evidence type (and associated schema) is defined and agreed by the Member States, all Member States know in advance which evidence type needs to be requested. However, the Once-Only Technical System also supports situations in which there is no single agreed evidence type that is harmonized across the EU and that all Member States can provide. The type of evidence that is used in the Member State that requests the evidence may not exist in another Member State. However, that Member State may be able to provide an “equivalent” evidence type, or even multiple “equivalent” types. Here, “equivalence” is used in the informal sense that the other type(s) can be used to prove the same claim about the citizen or business, or that the evidence type provides the same required information as the evidence type used in the Member State from which the request is made. In this case, the procedure can be executed using the alternative evidence type(s).

It is impractical to assume that an Online Procedure Portal in a Member State knows in advance which type of evidence to request, not just because this may differ for each of the many other source Member States, but also because the rules underlying the equivalence may change over time. Therefore, the Once-Only Technical System provides a common service, the Evidence Broker, which allows an Online Procedure Portal in a Member State to determine which evidence type it may request from another Member State for a particular purpose in a particular context. 

The Evidence Broker has a defined interface. It responds to requests that contain the following information:

• The Member State from which evidence is to be retrieved;
• An identifier of the requirement for which evidence is requested (information needed, criteria that need to be met);
• The context in which the request is made (life event, procedure, applicable Directive);
• Optionally, the geographic area code for the Member State in which the competent authority or intermediary platform that lawfully issues the evidence is based.

It will return, in response, the following information:

• A (possibly empty) list of the following information item pairs:
  • An identifier of an evidence type that satisfies the information requirement;
  • Optionally, for structured evidences, an identifier of a transformation that may be applied, if requested, to the evidence by the Evidence Provider.    

The ability to specify transformations that may be applied to evidences supports the data minimization requirement of the GDPR [REF21]. The provider can use a transformation to provide an evidence that more narrowly matches the relevant requirement, by removing unnecessary substructures and/or aggregating information.  However, this functionality is optional. If the competent authority or intermediary platform providing the requested evidence can only provide digitalised documents, instead of data, it is possible that the requesting authority or intermediary platform receives more personal data than strictly needed.  However, this situation is no different from those in which such evidence is submitted by the user. The SDGR does not aim to harmonise the format in which evidence is provided by the different competent authorities in the Member States. Until all administrations move to a system based on data instead of documents, the Once-Only Technical System will be able to accommodate both. 

This Evidence Broker service is based on rule content, provided by the Member States themselves. It provides an online mechanism for Member States to align and query their evidence requirements and evidence type sets. This obviates the need for full EU-level harmonisation of evidences types. The Evidence Broker allows Member States to manage and share information about rules relating to evidence types. As noted, for any evidence type, equivalence is relative to the purpose for which, and context in which, it is used.  

The data model and concepts used in the Evidence Broker are defined in the Core Criterion and Core Evidence Vocabulary (CCCEV, [REF40]), provided by Interoperable Europe [REF29]. Additional design documentation is available for the Evidence Broker [REF9]. 

In case where there are multiple options (multiple evidence types) for a particular requirement, the Online Procedure Portal may ask the User to select which (if any) option will be used, putting the user in control of the execution of the procedure.

Note that use of the Evidence Broker is not needed and its use is not required in situations where the evidence requester already has obtained the response information mentioned above.  

6.3. Data Service Directory

To request electronically available evidence from a Data Service in a different Member State, the portal of a public administration in a Member State needs data about the Data Service (such as the relevant eDelivery routing identifier) in the other Member State that may provide the evidence. The OOP Technical System includes a Data Service Directory which allows Member States to manage and share this information in a structured format. Its legal base is Article 5 of the Implementing Act. 

The Data Service Directory has a defined interface. It responds to requests that contain the following information:

• An identifier of the Evidence Type;

• The Member State in which Data Services for the identified Evidence Type are being looked up;

• Optionally, the geographic area code for the Member State in which the competent authority or intermediary platform that lawfully issues the evidence is based.

It will return, in response, the following information:

• A (possibly empty) list of tuples providing the following information:
  • The identifier code and identifier code type of the Evidence Provider served by the Data Service; 
  • The identifier code and identifier code type of the authority or intermediary platform that operates the Data Service Access Point used by the Data Service;
  • The required Levels of Assurance of the eID means notified in accordance with Regulation (EU) 910/2014
  • A list of additional attributes (if any) used to facilitate the identification of the relevant evidence provider, their formats and optionality. 

The Once-Only Technical System supports situations in which there is more than one Evidence Provider for an Evidence Type in a Member State.  In these cases, the user may help decide which (if any) of them will be queried, as he or she may know from which Data Service(s) relevant evidence(s) can be obtained. For example, in an educational procedure the user could select the university that he or she knows issued an educational evidence type for him/her from a list of universities, if universities in the relevant Member State use different Data Services.    

Additional design documentation is available for the Data Service Directory [REF8]. This work is based on open technical specifications and Interoperable Europe (formerly ISA²) specifications.

On the support of the Data Service Directory for identification and authentication, see section 8 below. 

6.4. Semantic Repository

In order to achieve semantic interoperability, Member States need to make detailed agreements on the semantics of evidence types that are to be exchanged using the OOP Technical System. The Semantic Repository supports this by storing and sharing definitions of names, definitions and data types of data elements associated with specific evidence types. Its legal base is Article 7 of the Implementing Act. This Repository is not used in the run-time exchange of evidences. Its purpose is only to support the Member States as they design and implement systems consuming or providing evidences.

The Semantic Repository contains:

• Visual class diagrams;
• Data models and definitions;
• Data elements and definitions;
• Distributions in XML schema (XSD) or equivalent formats;
• Code lists of information requirements;
• Code lists of evidence types;
• Other code lists, or references to code lists, used in the system;
• A methodology for developing new data models for structured evidence types.
• A mechanism for conversion into a human-readable format, such as .XSLT or equivalent

Additional design documentation is available for the semantic repository [REF28].

The Semantic Repository includes a generic metamodel that can be used for the exchange of arbitrary unstructured evidences.  It provides a light-weight generic mechanism to support the exchange of any type of evidences. It facilitates the automated exchange of either unstructured or structured types of evidence. This metadata model is in line with the Exchange Data Model used in Evidence Exchange. The data models for specific evidence types complement the generic metadata model and provide structured data models developed for a particular evidence type.

6.5. Life Cycle Management

The instances of the Evidence Broker and the Data Service Directory provided by the European Commission will provide interfaces that allows Member States to maintain (add, change, delete) content regarding evidence types available from them and data services that provide them, as stated in article 5.2 and 6.3 of the Implementing Regulation. Two interfaces will be provided:

• A user-interface that can be used by Member State representatives to interactively manage content;
• An automated bulk load interface that allows Member States to replace their partition of the content in the EC provided instances by an updated version.  

While the lookup query interfaces of Evidence Broker and Data Service Directory use a lightweight REST interface, the bulk load interface will use the existing Life Cycle Management service interface of OASIS RegRep [REF27] using eDelivery [REF13] in order to benefit from its advanced security and reliability.   

6.6. Deployment Options

As a reflection of the different implementation preferences of Member States, the deployment of the Once-Only common services Data Service Directory and Evidence Broker follows a hybrid model, in which:

• The European Commission will operate an optional EU-wide central service instance for the Member States. This instance contains metadata for those Member States that want to use this service instance. This instance allows metadata from these Member States to be searched by all participants in the Once-Only Technical System. Member States using this instance still need to provide and help maintain the metadata in the central service as discussed in section 6.5. 
• A Member State that wants to do so can operate and provide access to its own instance of the service. To retrieve data related to this Member State, this instance is used and there is no need to provide data to the EU-wide central service instance.  

The legal base for this deployment model is Article 8 of the Implementing Act.

The European Commission will provide a central registry in which connectivity information for each of the evidence broker and data service directory instances is published and provide a mechanism supporting dynamic discovery of these directory instances. More information on this registry discovery functionality is provided in [REF41].   

The model is illustrated for the Data Service Directory in the following diagram. It shows a situation in which Member State 1 uses the EC central Data Service Directory and uses the LCM interface mentioned in section 6.5 above to upload its data (step 1 in the diagram). Member State 2 provides its own data and does not upload it to the EU Central DSD instance. To discover which DSD to retrieve data from, Evidence Requesters may query the EU DSD Registry (step 2). This Registry will indicate that DSD queries for Member State 1 should be addressed to the EU Central DSD (step 3a), whereas DSD queries for Member State 2 should be addressed directly to its national DSD (step 3b).      

Figure 5 Hybrid deployment model for common services 

Note that there shall be no more than one instance of a common service for a given Member State. Therefore, a given Member State either has no service instance of its own, like MS 1 in Figure 4, or a single service  instance, as is the case for MS 2. No Member State shall have two or more instances. 

The lookup interface design documentation to be used for a service instance shall be the same for the European Commission-operated service instance and for any service instance operated by a Member State, following Article 8 of the Implementing Act [REF38]. The life cycle management interface is covered in section 6.5 above and in Chapter 3. 

7. Evidence Exchange and eDelivery

7.1. Introduction

Evidence exchange in the Once-Only Technical System is based on bilateral exchange between competent authorities. An exchange is always a pair of two correlated messages: 

• An evidence request message generated by an Online Procedure Portal in a Member State, supporting a competent authority or intermediary platform in the “Evidence Requester” role;
• A corresponding evidence response message generated by a Data Service in one or several other Member States, supporting a competent authority or intermediary platform in the “Evidence Provider” role.

For interoperability, the Once-Only Technical System defines in detail the structure and content and message exchange parameters.  

This version of the OOTS architecture maps any exchange of a piece of evidence involving preview to a sequence of up to two request-response message loops and an interactive redirect/return user flow. 

• In the first message loop:
  • The request message expresses evidence query parameters including the requested type of evidence, the user and the data subject.  It does not contain any hyperlink to the Preview Space. 
  • If a piece of evidence relating to the user may be available and preview is offered, the response message includes a hyperlink that the user may follow for the Evidence Preview Service. In this case, no piece of evidence is included in the response. 
• The second message loop is triggered by the user's decision to follow the presented link:
  • The request message has the same query parameters as the first request message but, in addition,  includes the hyperlink provided in the first loop response. This signals to the Data Service that the user is engaging with the Evidence Preview Service and allows the Data Service to coordinate its processing with that service.   
  • The response message in this loop includes all and only those pieces of evidence that match the query parameters, identity and any other parameters established in the interactive flow, reflecting user decisions on whether or not to use any matching available pieces of evidence. 

The response message in the first message loop can and must be returned instantly to ensure a smooth user experience. By contract,  the response in the second message is only returned when the user completes his or her interaction with the Evidence Preview Service.    

7.2. Integration and Service Interaction Patterns 

The Once-Only Technical System is based on a number of common patterns identified in technical literature such as Enterprise Integration Patterns [REF18] and Service Interaction Patterns [REF39].

The OOP Technical System uses the Request-Reply integration pattern, also known as the Single-Transmission, Round-Trip service interaction pattern. The exchange of evidences takes place between competent authorities, but never in isolation or spontaneously, always in response to explicit requests:

• Evidence requests are made by Online Procedure Portals in a Member State in the “Evidence Requester” role;
• Corresponding evidence responses are provided by Data Services in one or several other Member States in the “Evidence Provider” role.

The use of message-based communication components called Access Points in eDelivery is an instance of the Messaging Gateway pattern. A gateway is a component that is responsible for the implementation of messaging functionality according to the agreed interoperability design. Reusable Access Points make it easy to enable the use of eDelivery in Online Procedure Portals and Data Services by competent authorities and their service providers.

Access Points also instantiate the Messaging Bridge integration. The communication between the Online Procedure Portal and its Access Point and the communication between the Data Service and its Access Point may use different communication protocols and formats, which the Access Point helps bridge. 

In a particular step in a procedure, an Online Procedure Portal may issue multiple requests to different Data Services and collect the responses in parallel. In this case, the interaction follows the Scatter-Gather with Distribution List pattern. The service pattern is also known as the One-to-many send/receive service integration pattern and is Multilateral rather than Bilateral.

7.3. Evidence Request Response

The evidence request response exchange legs use generic structures based on a specified profile of the RegRep4 open technical specifications [REF27] and Interoperable Europe eGovernment vocabularies. The structures support transport, routing, packaging and correlation.

The request structure includes, following Article 13 of the Implementing Act:

• a unique identification of the evidence request;
• the evidence type that is requested; 
• date and time when the request was made; 
• identification of the procedure for which the evidence is required; 
• name and metadata that uniquely identifies the evidence requester and intermediary platform, where applicable; 
• the attributes of the user, or the user and the representative where applicable, exchanged using the electronic identification means referred to in Article 11(1);
• the level of assurance of the electronic identification means used by the user; 
• additional attributes used for selection of the evidence provider;
• the identification of the evidence provider as registered in the data service directory; 
• an indicator whether or not the user has provided explicit confirmation to request the evidence; 
• an indicator whether or not the user is required (by law applicable to the evidence requester) to offer preview that needs to be implemented on the EP side;
• in the second loop, the request also includes the hyperlink of the corresponding Evidence Preview Service.

Optionally, for structured evidences, an identifier of a transformation operation to be applied by the Data Service to the evidence before it is issued to the evidence requester may be included.

In response to a request message, an error message may be returned and no piece of evidence is included, following Article 15(4) of the Implementing Act. This shall include:

• a unique identifier of the error;
• the identifier of the evidence request to which the response relates, to support correlation;
• date and time at which the error was generated;
• a description of the error that occurred.

As a special category of error, in the first request-response loop, in case evidence may be available and is ready for preview, the response includes:

• A hyperlink that the user may follow to interact with the Evidence Preview Service.

The Online Procedure Portal shall recognize this situation and use the provided information to allow the user to navigate to the Evidence Preview Service in the Evidence Provider Member State.  This hyperlink shall never be included in errors returned in the second loop, i.e. in response to requests that contain the hyperlink.

In the second request-response message loop, any response that is not an error shall include the following elements: 

• a unique identification of the evidence response;
• the identifier of the evidence request to which the response relates, to support correlation;
• date and time at which the response is created;
• identifier code of the evidence requester and intermediary platform, where applicable; 
• identifier code of the evidence provider and intermediary platform, where applicable.
• For each evidence included in the response, the response includes:
  
  • evidence metadata as defined in CCCEV [REF40]:
    • Title; distribution; issuer; issue date;  language; validity period. 
  • an indication of the transformation applied, if any;
  • the evidence in electronic form;

NB: if the evidence request requested application of a transformation, the attached evidence is the output of the application of the transformation to the evidence. The optional requested transformation allows the requester to receive a more tailored version of the evidence, as explained above in section 6.2. Since this transformation is applied by the Data Service of the Evidence Provider, it is the output of the transformation that is exchanged as the authentic evidence in the Once-Only Technical System. It is protected by the integration and non-repudiation features of eDelivery.  

The syntax and semantic of evidence requests and evidence response is covered in the technical design documents [REF20]. 

Optionally, a Data Service may inform the requester that evidence may exist for the request, but is not yet available. 

7.4. eDelivery

The Once-Only Technical System reuses the eDelivery Building Blocking [REF11] and uses its Acccess Point [REF12] specification. See Figure 5 for an overview of its functions.

Figure 6 Access Point Application View

An Access Point in the Once-Only Technical System performs key security and reliability functions. It signs and encrypts messages and, in a delegated role, provides integrity, confidentiality, authenticity and non-repudiation of origin and receipt as explained in the Security Controls guidance document [REF14].

As noted above in section 4.3, the competent authority or intermediary platform that operates an Online Procedure Portal Access Point has a responsibility to make sure that it only issues evidence requests on behalf of requesting competent authorities that have an appropriate legal basis to make such requests, as required in recital 45 of the SDG Regulation [REF30].

7.5. Configuration of eDelivery 

Evidence exchange uses eDelivery Access Points as provided by the DEP eDelivery Building Block. It uses the ISO 15000 ebMS3 [REF26] and AS4 [REF25] standards profiled as eDelivery AS4 using the so-called four-corner topology profile enhancement [REF13].  The packaging of RegRep4 in AS4 and the values of key AS4 processing mode parameters and associated headers are specified in a separate open technical specification [REF1]. The four-corner topology applies to both the flow of the request from the Online Procedure Portal to the Data Service and the reverse flow from the Data Service to the Online Procedure Portal.

As the four corner topology profile enhancement is used, for an evidence request:

1. The competent authority or intermediary platform on whose behalf the evidence request is made is identified as original sender (Corner 1).
2. The competent authority or intermediary platform that operates the Access point is identified as the sender (the "From" party) of the AS4 message (Corner 2). 
3. The competent authority or intermediary platform that operates the Access Point for the Data Service is the receiver (the "To" party) of the AS4 message (Corner 3).
4. The competent authority or intermediary platform that provides the evidence is the final recipient of the message (Corner 4). 

Routing of eDelivery messages is handled as follows:

• The Data Service Directory provides both the identifiers of the evidence provider and of its Access Point provider. Therefore, any evidence request message can be routed appropriately, for any identified Data Service.  
• Evidence response messages shall be routed in reverse order, i.e. the final recipient value of the response is set to the value of the original sender in the request (C1 → C4), the response original sender value is set to the request final recipient value (C4 → C1), and the sender and receiver values are swapped (C2 → C3; C3 → C2).    

A single Access Point may serve any number of evidence requesters and/or evidence providers. If a competent authority or intermediary platform operates its own Access Point, then:

• Corner 1 and 2 are the same for outbound messages. The value of the AS4 sender header ("eb:From") shall be the same as the value of the original sender message property. 
• Corner 3 and 4 are the same for inbound messages. The value of the AS4 receiver ("eb:To") shall be the same as the value final recipient message property. 

All Access Points that are part of the Once-Only Technical System are statically configured to make evidence requests to, and respond to evidence requests from, all other Access Points. This configuration includes networking (e.g. firewall settings), transport layer security, message layer security (including certificates used for signing and encryption) and all AS4 processing mode configurations including endpoint URIs. 

Detailed information on the use of eDelivery in OOTS is provided in 4.7 - eDelivery Configuration (Draft).

The following diagram shows the integration of eDelivery in the exchange between an Online Procedure Portal and a Data Service. The Data Service Directory provides corner 3 and 4 routing identifier information for the request message. The Data Service reverse routes the response message to the Online Procedure Portal. 

Figure 7 Message exchange and routing using eDelivery Access Points and Data Service Directory 

The Once-Only Technical System does not provide end-to-end security: 

• Evidence requests and evidence responses are trusted based on the message signature applied by the sending Access Point. The OPP (for requests) and the DS (for responses) do not sign the content that they submit to the Access Point with an expectation that the DS (for requests) and the OPP (for responses) verify the signature. This obviates the need for sharing of signing certificates and agreement on trusted Certification Authorities between competent authorities that use the Once-Only Technical System.
• Evidence requests and responses are encrypted when they packaged and transmitted as eDelivery messages. The OPP (for requests) and the DS (for responses) do not encrypt the content that they submit to the Access Point with an expectation that the DS (for requests) and the OPP (for responses) decrypt the content. This obviates the need for sharing of encryption certificates and agreement on trusted Certification Authorities between competent authorities that use the Once-only Technical System.   

Member States are responsible for providing equivalent or better protection of evidence requests and responses in the exchange between Online Procedure Portals, Preview Areas, Data Services, any other intermediary components and their respective Access Points (i.e. between C1 and C2 and between C3 and C4). 

Exchange of eDelivery messages between Access Points shall use the public Internet.  As specified in the eDelivery AS4 specification, eDelivery is secured at both the transport layer and the message layer. This provides integrity, authentication, confidentiality and non-repudiation of origin and non-repudiation of receipt at a level of protection comparable to the use of a private network.

A Member State may deploy a single Access Point covering all OOP-related eDelivery messaging. Alternatively, it may deploy multiple Access Points at any hierarchical or geographic level of the public administration, in addition to potentially having specialised Access Points for specific domains. 

Since the Once-Only Technical System supports interactive use cases, the integration of Access Points to the national systems on the Evidence Requester and Evidence Provider sides must be configured to minimize the latency, for example by avoiding polling interfaces or setting the any polling intervals to sub-second values.  

7.6. Use in complex scenarios

The Once-Only Technical System does not provide any specific functionality beyond the exchange of pairs of evidence requests and responses. There are no mechanisms to link different subsequent uses of the system by the same user. This does not mean that it is not possible or useful to use the system in situations where one procedure is dependent on another procedure. 

For example, the system can be used for procedures involving registration and related de-registration. An example of this is shown in the following figure. Here, the user performs a registration procedure in Member State A. The output of this procedure is created as an output of this procedure in a registry in Member State A. The Once-Only Technical System can be used as an input in a separate de-registration procedure in Member State B. (For simplification, the diagram does not include interaction with the Preview Space).

Figure 8 Once-only Technical System supporting registration and Deregistration 

Note that this example assumes that the registration evidence is input to the subsequent de-registration procedure. In other situations, the registration procedure may use output from a prior de-registration procedure.

7.7. Intermediary Platform

In some Member States, some evidences are not provided directly by individual competent authorities but by entities that the Implementing Act calls "intermediary platforms".  An intermediary platform is a technical solution acting in its own capacity or on behalf of other entities such as evidence providers or evidence requesters, depending on the administrative organisation of Member States in which the intermediary platform operates, and through which evidence providers or evidence requesters connect to the common services referred to in Article 4(1) or to evidence providers or evidence requesters from other Member States provide such evidences in a delegated capacity. For example, there may be a dedicated service organisation in a Member State that stores and makes available, on request, educational evidences on behalf of many educational institutions, such as universities. The Implementing Act, Article 1(6), refers to these organisations as Intermediary Platforms.

Use of such a platform may simplify the use of the Once-Only Technical System on the Evidence Provider side:

• Only the Intermediary Platform needs to implement a Data Service for the type of evidences that it makes available;
• Only the Intermediary Platform needs to implement (or connect to) an Access Point and needs to be integrated in the Once-Only Technical System;
• The evidence providing competent authorities that use the Intermediary Platform do not have to join the Once-Only Technical System directly themselves; 
• Evidence requesters that look up the provided evidence type in the Data Service Directory will find only one Data Service in the Member State. This means that there is no need to determine which Data Service(s) (potentially among many) to send the evidence request(s) to, and therefore no need to consult the user to select a Data Service.
• Implementation, testing, configuration, maintenance, etc. are all simplified.

An Intermediary Platform may also simplify the use of the Once-Only Technical System on the Evidence Requester side:

• It could provide the functionality of the Once-Only Staging Area to Online Procedure Portals and the competent authorities served by those portals;
• Online Procedure Portals that use the platform do not need to operate client interfaces to the Common Services themselves;
• The platform could implement eDelivery for the Online Procedure Portals by providing (or connecting to) an Access Point.

Whether or not a Member State uses a (or some) Intermediary Platform(s), and which competent authorities should use the (or a particular) Intermediary Platform, is at the Member State's discretion.  

An Intermediary Platform also instantiates the Messaging Gateway and Messaging Bridge integration patterns. In addition to bridging messaging protocols (e.g. eDelivery AS4 to other protocols used within the Member State), functionality provided may include:

• Mapping between national party identifier code systems and cross-border identifier code systems;
• Mapping between data formats, schemas, code lists;
• Mapping between synchronous and asynchronous communication;
• Service Bus connections;
• Aggregation services (e.g. combine information from multiple Data Services). 

The concept of an Intermediary Platform is also sometimes known as a "Single Window" or as a "Data Aggregator". 

7.8 Evidence Exchange Logging

To support the OOTS, events related to the use of the system need to be logged. Legal requirements for logging are defined in Article 17 of the draft Implementing Act, with the specifics for evidence exchange being covered in Article 17(1). Due to the OOTS being a distributed system, evidence exchange events occur and are logged in the various components involved in the execution of the evidence request and response flows.  The design section on 4.8 - Evidence Exchange Logging further describes the correlation identifiers that are generated and processed in the various components and how they allow end-to-end tracking and tracing.

In OOTS, evidence exchange event logging supports audits and security checks, but also the usual tasks of deployment, integration, testing and operation of parts of the system.  The logging of eDelivery event data serves the important additional purpose of non-repudiation of origin and receipt for OOTS evidence exchange.  

7.9 Evidence Exchange integration in Member States 

The OOTS uses the four-corner topology model for eDelivery. The profiling of eDelivery AS4 as defined in section 7.5 and in 4.7 - eDelivery Configuration only applies to the cross-border eDelivery message exchange, not to the communication between components within the Member States. Member States have a wide variety of existing national eDelivery systems or other intermediary components based on national standards and infrastructure that may be re-used for OOTS. The details of these national evidence transmission infrastructure are out-of-scope for OOTS, except for the following general requirements: 

• The confidentiality, integrity and authenticity of the communication of evidence requests and responses in the exchange between Online Procedure Portals, Preview Are as, Data Services or other intermediary components and their respective Access Points (i.e. between C1 and C2 and between C3 and C4) must be protected at a level that is equivalent to or better than that provided by eDelivery Message Exchange. 
• The communication of evidence requests and responses must include all data elements required for enabling logging for end-to-end correlation, tracking and tracing of data flows, in order to support end-to-end tracking and tracing as specified in  4.8 - Evidence Exchange Logging. 

On the Evidence Requester side, the following additional requirements apply: 

• Mechanisms must be in place to ensure that Online Procedure Portals may only request pieces of evidence that are lawful in the context of the electronic procedure that the user is executing.  
• Unless the exemption of Article 14(5) of the SDG regulation applies, the Data Service shall not make available any pieces of evidence without preview and approval by the user that the evidence may be used in the procedure. 

8. Identification and Authentication

8.1. Introduction

The architecture of the Once-Only Technical System reuses the eID building block as it is today. Should the eID building block change, the technical specifications would be adapted to support the changes.

8.2. eIDAS Node

The use of eIDAS nodes is discussed in sections  4.4 and 5.5. The purpose, use and specifications of eIDAS Nodes are specified in the existing, separate eID Building Block [REF17]. They are reused in the Once-Only context.

Note that in some procedures, for some users, a national eID that has been notified may be used without the need to use the eIDAS Node. This is the case for a user that executes a procedure in Member State A, has a national eID issued by MS A but wants to use evidence from MS B. This is an option irrespective of the nationality of the user as Member States may notify eID schemes that issue eID means also to foreigners. In order to be used the eID means from MS A must be issued under an eID scheme notified according to Article 11(1) of the Implementing Act . 

Note that eID means issued under notified eID schemes may differ in level of assurance and that the Online Procedure Portal and Evidence Provider define which level they expect.

The Once-Only Technical System distinguishes the identity and authentication of natural persons and legal persons and representation, if supported by the eID service used.

8.3. Identification and authentication

In the execution of an electronic procedure, there are two situations in which the user can be identified and authenticated:

• to use the procedure;
• to use the Once-Only Technical System to retrieve a particular evidence.

Identification and authentication performed by the Evidence Requester must use electronic identification means that have been issued under an electronic identification scheme that has been notified in accordance with Regulation (EU) No 910/2014. If the access to the procedure has been granted without the fulfilment of this requirement, the Evidence Requester must ask the user to re-authenticate taking into account the previously mentioned requirements before using OOTS.

The mandatory attributes of the eIDAS minimum data set obtained as a result of a successful authentication at the Evidence Requester side, as described above, are added to the evidence request.

If eIDAS optional/sector specific attributes are received by the Evidence Requester, and it is in accordance with the national privacy policy, these attributes may also be included in the evidence request.

The mandatory attributes of the eIDAS minimum data set, with the exception of the Unique Identifier, must always be provided in the evidence request, together with the Level of Assurance. When the Unique Identifier is derived receiving-MS-specific, it means that the Unique Identifier changes for each Member State. Therefore the Unique Identifier obtained by the Online Procedural Portal is specific to the Member State of the Online Procedure Portal and should not be used in another Member State. The information about the Unique Identifier is communicated during the notification process and more information is available in chapter 2.  Additionally, this information could be provided by the eIDAS Cooperation Network. The Data Service may rely on person identification data received or choose to ask the user to re-authenticate. If the user is re-authenticated, the Data Service must ensure that the attributes received match the ones that ones held by them. More details on this can be found in 2.1 - Identity and Record Matching.

8.4 Identity Matching

As part of user identification and authentication, a relying party, as defined in eIDAS technical specifications, commonly wants to know whether the claimed identity can be found in their records as an identity who is authorised to access that service or data. In the use of electronic procedures, such identity matching may be needed at two points in time:

1. When the user authenticates in order to interact with the Online Procedure Portal. This authentication involves the use of notified eID and depending on the issuing Member State the use of eIDAS nodes. This step is typically needed for any interaction with an electronic procedure, including interactions that do not involve the use of the Once-Only Technical System. 
2. As part of the processing of an evidence request by a Data Service in the context of the Once-Only Technical System. This could be done using the identity attributes received in the evidence request or by requiring the user to re-authenticate.

Note that the eIDAS minimum data set may not be enough to properly identify a foreign user according to national rules. Therefore, a procedure for first authentication is usually made available and the Evidence Provider may request to re-authenticate the user.

The identity matching functionality needed for authenticating the user to an online service may be part of the functionality of an interactive service or it may be provided by a dedicated (typically centralized) Matching Service. How this is implemented for a Data Service is up to the Data Service, taking into account the national set-up. 

8.6. Representation

Several of the procedures in scope of OOTS, for example those listed in Annex II of the SDG regulation, are procedures about legal persons. In these procedures, Evidence Requesters typically need to be able to authenticate a legal person (legal person as defined in Article 3(3) of Regulation EU No 910/2014) or establish that the user has the power to represent the legal person (natural person representing a legal person as defined in Article 3(3) of Regulation EU No 910/2014) in the electronic procedure in order to be able to proceed with the application. This requirement applies whether or not any evidences are exchanged in the electronic procedure and is therefore independent and separate from the Once-Only Technical System.

The Online Procedure portal shall rely on electronic identification means defined in Article 3(2) of Regulation (EU) 910/2014 issued under the electronic identification schemes notified in accordance with that Regulation. The identity attributes obtained as a result of eIDAS authentication of legal person or natural person representing a legal person will be included in the evidence request. The Data Service may use these identity attributes for the identity and record matching or it may choose to re-authenticate. In case of the latter, the Data Service must ensure that the identity attributes received match the identity attributes retrieved during the re-authentication.

To express the power of representation scope of a representative person representing a different represented person, the sector specific "PowerOfRepresentationScope" attribute MAY be included in OOTS evidence request messages. 

8.7. Additional OOTS eID security services

Once-only toolbox offers the competent authorities in a Member State to use in their implementation of the Once-Only Technical System opt-in elements, amongst which there are eID additional security services: 

• An authentication verification service that a Data Service can use to verify that the user identity attributes in the evidence request link to a recent eIDAS authentication transaction.
• Authorization of requests for evidence relating to represented persons.

Data Services may benefit from an authentication verification service that allows them to verify that an eIDAS authentication took place for a user. The verification shall match the provided identity attribute values and indicated level of assurance in the evidence request, make sure that this authentication took place sufficiently recently to be plausibly related to a single user session and was made by the user for the execution of an electronic procedure in the scope of the SDG. This opt-in feature could be used in the case where the Data Service would like to rely on the person identification data received from the Online Procedure Portal, without re-authentication.

A Data Service, should the national set-up allows it, may benefit from a service (for example, a Mandate Management Service) that can validate whether the representative is authorized to obtain evidence for the represented person. 

9. System Operation

9.1 Introduction

To support the operation of the technical system, additional constraints need to be adhered to.  

9.2 Log System

The legal base for logging in the technical system is provided in Article 17 of the draft Implementing Act.

The approach to logging in the technical system reflects its distributed nature.

The actors performing logging are:

• Member States as evidence requesters and providers ​
• Commission (and some Member States) as provider of common services

The information to be logged is:

• Evidence request metadata​
• Evidence response metadata or error metadata​
• eDelivery event data (message sent, received, acknowledged, acknowledgment received, any errors) ​
• Use of common services

Confidentiality, integrity and availability of the logs need to be applied.  Note, however, only evidence request metadata includes personal information. 

10. Sample Once-Only Flows

10.1. Sample Flow

The sequence diagram in Figure 10 shows a sample execution flow of a procedure where the user involved uses the Once-Only Technical System.  It is not normative and provided as an illustrative example only.[2] The diagram assumes "Once-Only"-specific functionality  on the Evidence Requester side is handled by a separate Once-Only Staging Area sub-portal. The diagram shows a single successful flow that involves preview. At many stages there is more than one potential next step, including error situations, which are not shown in the diagram - the diagram shows only ideal user progress through the system. Furthermore, the use of eDelivery (using Access Points) is omitted from the diagram. Refer to chapter 7 to see how use of eDelivery Access Points can be represented.

Figure 10 Once-Only Technical System Flow

The diagram shows an approach that maximises interaction with the User. This goes beyond the strict requirements of Article 14, which only mandates the preview feature, but it follows the principle of giving the user full control of their evidence when interacting with the Once-Only Technical System.  

The following table provides more in-depth explanations of each step in the sequence.

[1] The sources of all Archimate models in this document are publicly available at https://code.europa.eu/oots/tdd/hla. 

[2] The sources of all UML models in this document are publicly available at https://code.europa.eu/oots/tdd/hla.