Interdisciplinary Questions

The PSA collected 25 interdisciplinary questions as basis to provide guidance to the pilots. For each of the Reference Interaction Patterns, working hypotheses were formulated for the interdisciplinary questions relevant for that specific pattern. This helped to contrast the pattern and make the implications clear for policy stakeholders.

Orchestration / Choreography

The automated cross-border exchange of evidence requires many actors and systems to collaborate in an orderly manner, as also identified as barrier in D1.7: T3: The managing and governance of the choreography of distributed components managed by different agents and during a single user session. The sheer number of possible combinations in different procedures means that most combinations cannot be tested prior to first operational use. The more so, a solid concept of coordinating the actions and services required for the OOP exchange of evidence is required, irrespective of it being central orchestration or decentral choreography.

This need is further aggravated in Interrupted scenarios, which might include extended pauses or waiting periods in the overall process (i.e. issuing the evidence needs several days). Restricting the system to only uninterrupted exchange simplifies the challenge somewhat, but essentially, we still need to manage the interaction between User, DC, potentially several DP and several organisations in-between facilitating the exchange. In addition, we expect that a purely uninterrupted scenario might be too restrictive to cover the breadth of real-life scenarios.

Complementary, overlapping or conflicting evidence equivalents

We need to consider that the request for evidence in one country can lead to the identification of a multitude of available equivalents in other countries. This leads to the need for disambiguation: The equivalents can be complementary, meaning that several pieces of evidence are needed jointly to be equivalent. They also could be overlapping, meaning that several equivalents are available for a required evidence or criterion, yet all are valid; or they could be conflicting, which would mean that at least one of them is not correct. The underlying reasons for such situations could be complex real-life cases (e.g. multiple nationalities or complex life journey through several Member States), or the result of poor data quality across unreconciled registries in different Member States. In any case, the once only technical system will need to be robust against such cases and cannot assume a single request to single evidence case to be the only viable standard situation. Please note that this topic is about disambiguation, as opposed to cases that rightfully and correctly have multiple evidences involved in a single eProcedure (see Multi-evidence Cases in this chapter below).

Interrupted vs. Uninterrupted exchange

In the SDG context lives a strong assumption that the complete evidence exchange will be handled in an uninterrupted way within the timelines of a single user session, as part of completing an e-procedure. From Member State experience, we see that there are good practical and technological reasons to also consider scenarios where the evidence exchange is interrupted and can be resumed later (in the SDG context, the term “deferred response” is used at the moment). One practical reason is, for example, that some requested evidence is not immediately available in a format that allows for its automated exchange but can be made available at a later moment. Several member states have a mechanism to digitize the requested evidence on demand. Including this possibility would increase the volume of evidence that can be made available through the system. Also, in the multi-evidence case, when two or more evidences needs to be collected, it may not be feasible for the user to complete the procedure in one take. This topic was also recognized as organisational barriers in D1.7: O1: Data may be not ready for access in real-time without authorisation by a civil servant, and OP2: Data may not be ready for access in real-time without following procedures involving batch processing.

Also, a hybrid case appears to make sense, where the resume functionality serves as fall-back to handle exceptions in an a-priori uninterrupted procedure. It must be considered, however, that supporting interrupted procedures (resume functionality) across a multitude of cross-border participants is a very complex challenge involving correlation across highly independent systems and persistence (and consequently clean-up) of process instances.

Explicit request and transitivity between actors

In the SDGR, the exchange of evidence is generally initiated on explicit request of the user (except where the relevant Union or national law allows for automated cross-border data exchange without an explicit user request). This request is issued to the DC. It remains unclear whether that explicit request needs to be provided as well to the DP, in order for them to check the request prior to actually extracting the evidence back, or the DP can simply trust a request from a DC to be based on an explicit request or applicable law. The Data Protection Impact Assessment (DPIA) of the SDGR Art. 14 Implementing Regulation (version April 2021), for example, expressed that the Explicit Request does not need to be handed over to the DP. Later versions of the (yet to be adopted) Implementing Regulation, however, still explicitly include extensive information about the Explicit Request in the Evidence Request message from DC to the DP.

The political relevance of this topic become clear when looking at findings of D1.7 Legal, technical, cultural and managerial risks and barriers: more that 70% of the responding MS expressed that they are 'very cautious' when Sharing personal data with other countries and 67% reported that their national OOP approach requires 'Prior request from the user' before sharing data with other administrations within their country.

Preview & Approval UI

A lot of discussion already went into the topic of user preview and approval prior to completing the exchange of evidence. From a legal and data protection standpoint, we consider a preview prepared by the system of the DC as not optimal, because it would require the evidence to be already transferred prior to the preview. From a solution point of view, however, a preview provided by the DP would introduce several additional complexities, e.g. related to the handover of the user session from DC to potentially several DPs. We should consider the need for a user interface for the once-only technical system that is separate from the eProcedures form itself. Consensus on this point between Member States and the Commission is not yet final and the PSA includes reference interaction pattern for all three cases: preview at the DC, the DP or the U.

Identity and Record Matching

This is the problem of matching the eIDAS attributes (mandatory and optional) to the national identification numbers required to extract the evidence. Basis for this matching are the eIDAS mandatory and in some cases the optional attributes. This issue arises both at the DC in starting the online procedure as well as the DP side for extracting the requested evidence (see #Transitivity of user identity below), as mentioned in D1.7: S5: Identity/record matching when accessing online services cross-border and S6: Identity/record matching of user for data request and data access.

As this match is not 100% an exception flow is required. This still needs discussion as it either leads to the OOTS not being available for the user (a potential solution for the Minimum Viable Product (MVP)) or might require more complex user interaction, potentially even involving manual work by a civil servant or the provision of additional evidence. In this way this is also related to the topic of interrupted procedures above in #Interrupted vs. Uninterrupted exchange.

Transitivity of user identity

This problem arises in the Intermediation Pattern, because the user first authenticates himself vis-à-vis the DC. It is however the DP in another MS that needs to retrieve the evidence related to that user. This often requires a unique identifier, for example the one in the population registry, to access natural person information. The identity of the user (e.g. coming from eIDAS) is unfortunately not transitive (i.e. eUniqueness IDs differ between Member States). This topic related directly to the barrier 'L8: Identity transitivity cross border' identified in D1.7

As a result, the DP needs to re-establish the identity of the user, i.e. as described in #Identity and Record Matching above by matching eIDAS attributes to national records. This has again two implications: First, the match can be ambiguous (especially for common names where transliteration and similarity algorithms are needed following language rules specific to each Member State). Second the DC must be legally allowed to transfer the eIDAS attributes to the DP.

In the business domain, this is simpler to resolve as a European Unique Identifier (EUID) for companies exist since 2012. The EUid for Citizen, proposed for the current eIDAS revision should help to resolve this problem as well for natural persons in the Union.

Hand-over of UI between actors

If the eProcedure including the OOP transfer requires several systems, controlled by different actors in different MS, to interact with the user, then a UI reference would need to be handed on throughout the OOP evidence exchange. The likeliness for such a hand-on to break along a longer procedure is significant, which would again give rise to the need of supporting interrupted procedure as described in #Interrupted vs. Uninterrupted exchange above.

Mandate and Proxy

The power of representation, either a natural person representing a legal person (i.e. mandate) or a natural person representing a natural person (i.e. proxy) or even a legal person representing a natural person is a complicating factor in the identification and OOP exchange of evidence that we cannot ignore. It is also identified as one of the most critical barriers in D1.7: S8: Non-harmonised (or mapped) user rights, including powers and mandates.

Whereas a first implementation for citizen procedures might still put this out of scope, it is surely required in the mid-term solution (time horizon t=3 [6]), e.g. because of the aging population of the Union. For business-related procedures, this issue must be tackled from the start, as it is always a natural person representing a legal person. The long-term solution should also consider chaining together ‘representation’-relationships or ‘intermediaries’ (e.g.: an accountant representing an accounting firm that represents a trading company that represents a manufacturer).

Successful piloting might require an eIDAS extension for powers attributes (i.e. SEMPER). Some partners may be hesitant to deviate from using their eIDAS reference software in production.

Encryption Gap

The existence of a national OOP system in many MS means that the roles of Data Requestor (DR) and Data Transferor (DT) will be taken over by central MS organisations that are separate entities or authorities from the Data Owners (DO) and Data Evaluators (DE). This is fully in line with the 4-corner model. This means that it is likely that the gateway between the national OOP system and the European cross-border OOTS will need to decrypt and then re-encrypt the evidence using the national and the European standards, respectively. Consequently, the evidence is available at some point in unencrypted form while being processed by the gateway. Real E2E encryption, which would result in nesting encryptions, could theoretically solve this problem on the technological level. It creates, however, two new challenges: one related to managing certificates across many thousands of competent authorities and the second related to the user preview.

Structured data vs. unstructured data

In how far only structured or also unstructured data is to be supported by OOTS. The SDGR is explicitly not making a choice in this regard, however the solutions discussions are often assuming a structured data exchange. The consensus is not yet final, and we expect this to be one of the topics that remain unclear at least until the completion of the implementing act mid-2021.

If we refer to structured data, we mean electronic data that is adhering to some defined and known, domestic schemas or data models. It is important to note that this means that ‘structured data’ is not equivalent to data in data bases. Also, a structured data document adhering to a known schema is structured data. A document with “some text” or a randomly named image file (of a scanned document) is considered unstructured. Additionally, evidences from different domains might use different data models and schemas, it is important that the data models are defined and known.

This discussion is often confused with the assumption of automated re-use of data after transfer (cf. #Automated re-use of data below).

Automated re-use of data

Related to the structured data discussion (see #Structured data vs. unstructured data above), is the widely held, implicit assumption that data can be automatically reused after exchange in the systems of the DC. Structured data is only one of the prerequisites for automated data re-use. Fully enabling such an automated reuse requires not only: 1) Structured data but also 2) established semantic equivalence across MS and 3) compatible data formats and attribute domains that lend themselves to automated transformation and re-use. Without going into the details of different transformation requirements (e.g. reversible vs. irreversible), it becomes apparent that enabling automated reuse of data is a major challenge across MS, which is also apparent in the barriers identified in D1.7: S2: Evidence Format and cross-MS Compatibility of Formats and S3: Missing Semantic mapping of data elements.

The way semantic equivalence and data format compatibility can be achieved is a closely related discussion. In simple terms, the two standpoints are:

a) Harmonization of data definitions (semantic standardisation and standardisation of the syntaxes, i.e. data formats used) through negotiated agreement either by the legislator (e.g. Directive 2016/1191) or by voluntary consensus (i.e. Health domain) b) Use of semantic technologies to map different ontologies onto each other, potentially involving machine learning (e.g. used by e-commerce platforms and data aggregators)

Production system and real-life cases

The optimal outcome of the DE4A pilots are systems that add real value to the citizen and enterprises of the participating Member States. There are, however, significant impediments or hard-to-overcome challenges that could make full production go-live impractical or even impossible. Examples are extensions of the eIDAS nodes to support mandates and proxies (see #Mandate and Proxy) or the use of non-notified eIDs. These adapted systems would need to run in “acceptance environments” but could still interface with production systems (i.e. identity service providers) and pilots could still be based on real-life cases.

Another example is the availability of a legal basis for issuing evidence to competent authorities in another MS (cf. #Explicit request and transitivity between actors). Piloting, using real-life cases, can be seen as a required part of developing the OOTS prior to 12.12.2023. Consequently, it is considered to be covered by SDGR Article 14(11). While this interpretation would support piloting, it implies that the pilot solutions can transfer to full production use only after SDG Article 14(1) to (8) and (10) entered into force 12 December 2023. Approaches like signing a Memorandums of Understanding between piloting Member States (authorities) can alleviate this limitation and substantiate a consensus on the interpretation of Article 14 (11).

EESSI integration

Electronic Exchange of Social Security Information (EESSI) is a domain specific, sectoral network that has some overlap with the third use cases in the DE4A Moving Abroad (MA) pilot, i.e. - Request Pension Information & Claim Pension, - both in regard to relevant authorities and to exchanged information. The MA pilot needs to assess whether some EESSI capabilities can be reused. This reuse can take different forms, reaching from a full adoption of EESSI for the use case, via a bridge solution that that would use EESSI as a DP on European level, to the adoption of harmonised data models and definitions.

BRIS integration

Business Register Interconnection System (BRIS) is a domain specific, sectoral network that has some overlap with the use cases in the DE4A Doing Business Abroad (DBA) pilot, both in relevant authorities (i.e. business registers) and in exchanged information. Even if BRIS can only be used by (a subset of) business registries themselves, it already provides today an operational exchange of company information across Europe. A reuse of (an extended) BRIS is understandably in the interest of the participating business registers, however, the possibility of DE4A to create legal and technical changes on the existing BRIS system is very limited. Analysis of the DBA pilot shows that the potential of reuse of BRIS is limited for the pilot, i.e. will remain at the level of the reuse of data definitions.

eIDAS and national authentication systems

The question of user authentication in OOP centres around the use of eIDAS, after all this is what eIDAS is there for, to provide cross-border authentication. To focus exclusively on eIDAS might be too restrictive as it would exclude an important user group, namely users that have an eID of the DC country, encompassing own nationals and immigrants. In addition, the current state is that most eProcedures are designed for use by in both national and cross-border settings and we can safely assume that this will remain the case. This means that the eProcedure offers authentication via the national eID scheme or eIDAS as two alternatives.

Having both eIDAS and the national eID supported can in some cases resolve the issue if a MS has no eIDAS node operational, although this strictly limits the pilot population to users that have (already) an eID of the DC country. At the moment, Romania has no eIDAS node operational; Netherlands and Slovenia support only eIDAS IN.

Non-notified eIDs

Until now the pilots can only move to production with MS that notified their eID. Not all partners have notified so far. This might limit the possibility to pilot on production environments with all partners. An upcoming eIDAS node release, supporting the usage of non-notified eID’s might solve this issue to a certain extent. Further research is needed though. Austria, Slovenia and Romania have not notified yet their identification scheme.

Payment for evidence

As defined as one of the organisational barriers in D1.7 Some competent authorities charge fees for retrieving or issuing evidence. Pricing models usually cater for national data consumers, not for cross-border users. There could be a legal or financial arrangement for the piloting phase (and preferably beyond). It is important to understand that the payments can also be required between DC and DP and not only between U and DP. This is in line with the barrier 'Access to data may be subject to charges' identified in D1.7.

Trust Management

A consistent framework is needed that provide trust services across the complete OOTS. Having several PKI in parallel and different nested encryptions will make the overall system unmanageable. In simple terms: we need to make sure that the OOTS is not drowning in key and certificate management complexities. T2.2 set out to develop this trust architecture, initially based on mature technologies and then extending it to include the capabilities of modern blockchain technologies.

Irrespective of the technical representation of trust relationships, there might also be an organisational interoperability barrier related to trust. On the one hand, the question whether a DP in one country trusts the DC in another country to handle the exchanged evidence in a trustworthy way. On the other hand, a DC in one country trusting a DP in another country to provide evidence that is correct, up-to-date, and truthful. This issues go beyond the scope of the DE4A pilots, however, discussions around authorization (which DC is allowed to request what type of evidence) or the discussion whether the DP can rely on an explicit user request issued to the DC or must evaluate such request independently of the DC (see also #Explicit request and transitivity between actors) are all influenced by the barrier of 'Lack of trust (cultural) cross member states' identified in D1.7.

Legal basis for SSI and block chain technology

There are several legal concerns related to Self-Sovereign Identity and Blockchain technology, such as the storage of personal data in distributed ledgers or the validity of a decentral identifier. This led Spain to all but ban blockchain from application in eGovernment. By RDL 14/2019 it is forbidden to use a blockchain infrastructure to offer any identification or signature process (until a European or national law regulates the use of these technologies). Ongoing research, discussions, and progress in context of EBSI and ESSIF are clearly relevant for DE4A. It cannot be ascertained yet whether piloting use cases applying blockchain technology can go live in production or would remain exploratory, running in acceptance environments.

Explicit scope of Article14

The Blueprint of CEF Preparatory Action on OOP adopted a strict interpretation of Article 14: “this exchange pattern is the pattern specified in Article 14. This will therefore become the default evidence exchange pattern of the OOP technical system”.

This should not restrict DE4A to explore other interaction patterns for several reasons: First, initial discussions show that a translation of the legal text into requirements and further into an optimal solution provides more degrees of freedom than implied by the current blueprint version. Second, the blueprint is focused on meeting the 12.12.2023 deadline, with is not the end, but the start of the Once-Only Technical system. Third, the scope of DE4A is wider than the scope of the SDG implementation.

Matching Evidences between Member States

Evidences that cater for the same or similar life events or public procedures are very heterogeneous across MS, as was confirmed by a Study on Data Mapping for the cross-border application of the Once-Only technical system SDG [11] and corresponds to the barriers for Once Only, identified in D1.7: Data incompatibility, and Semantic incompatibility of information systems and datasets. This means that in many cases the evidence type required for a procedure in the DC country is meaningless for an evidence issuing authority in the DP country and vice versa. This extends well beyond the question of different languages into the definition of the evidence type itself, the structure and the semantics of its contents.

There is a considerable difference between domains where harmonised evidence types and corresponding schemas and definitions exist and domains without such prior harmonisation, which pose a much larger challenge. The approach for matching required evidences (DC side) and available evidences (DP side) could consequently also differ between harmonised and non-harmonised sectors. DE4A is designing different data models, services and components in the context of the Semantic Framework of WP3.

A good example of the complexities involved are university degrees. Even if the Bologna Process harmonized the three cycles of higher education in the EU, the equivalence of studies and subjects is not established. Trying to offer equivalence between subjects in different degrees in different universities and different countries may be a titanic effort as it extends from the schema (a degree relates to a specific subject of study) to the definition (is it just the study, or is it more specialized, like a set of five subjects in a degree allows a specific mention in a Master’s degree) to the attribute domain (which would be the official list/catalogue of studies and subjects in the EU). Relevant on-going efforts (e.g. EAR project, ENIC-NARIC Network) will be considered in the Studying Abroad Pilot.

Multi-evidence Cases

A Multi-evidence Case is an interaction between Data Consumer and Data Provider, where the Data Consumer needs to request several pieces of evidence for a single eProcedure from one or more Data Providers. Multi-evidence Cases implies a more complicated scenario for the involved actors and may require multiple requests, previews, responses as well as aggregating evidences. The implications of Multi-evidence Case depends on the interaction pattern used in the procedure, e.g. intermediation, user-supported intermediation or verifiable credentials. The Table below shows four distinct reasons for the Multi-evidence Case to arise.

Reasons for Multi-evidence Cases

	Multiple Data Providers	Multiple Evidence Types	Multiple Evidences of the same type	Evidences for multiple subjects
Description	Multiple Data Providers, either one or several evidence types for the same subject (one user = single subject)	Single Data Provider, multiple evidences of different types for the same subject (one user = single subject)	Single Data Provider, multiple evidence of same type for the same subject (one user = single subject)	Single Data Provider, multiple evidence of same type for different subjects (one user, multiple subjects)
Example	Example from Moving Abroad Pilot: For change of address, several evidence types are required, such as evidence of birth, place of residence, pension claims and income, which are for most MS issued by diferent Data Providers.	Example from Moving Abroad Pilot: In some MS (i.e. ES, SI), a national data portal consolidates evidences from different DO:s and doing so acts as a single Data Provider for several evidence types.	Example from Studying Abroad Pilot: A student who has multiple diplomas that can be sourced from the same Data Provider. (This can be either the same University or a national diploma repository, holding diplomas from different education service providers).	Example from Moving Abroad Pilot: A family is moving abroad. In that case a parent might run a single eProcedure instance requiring evidence (e.g. place of residence) from all their family members (e.g.: partner, kids, dependent).
General approach	Several Evidence Requests, resulting in several Evidence Responses, all holding essentially one single evidence.	The Evidence Request and Evidence Response should include multiple canonical evidence IDs and evidence definitions respectively. The request and response would consequently hold an array of evidences. The number of evidence types in the Evidence Request can differ from the number of evidence types that are actually in the response. [Note: change request to WP3 IEM]	The Evidence Response should include multiple evidence definitions. This means that there is a 1:n relation between requested canonical evidence IDs and issued evidences.	Two options: (1) Multiple eIDAS authentications, including the representation relationship (one authentication per subject), would need to be used, given the limitation of eIDAS, even if extended with concepts from SEMPER. (2) Leave it to the Data Provider end-point to validate the representation relationship; which is the preferred option. This means that the Evidence Requester needs to collect identification information (e.g.: first name, last name, date of birth) that the Evidence Provider can match with their representation registry. The Evidence Request should allow to specify different subjects for either a single or several different canonical evidence IDs and the Evidence Response should include several evidence definitions related to different subjects. This does not mean that here are different users! Using the second, end-point centric, approach does not have any impact on authentication and record matching for the user. It adds a separate record matching challenge for dependent subjects (i.e. children).
Working Hypothesis for USI	If Data Providers are not highly integrated on MS-level, then the users needs to re-authenticate on several different platforms and perform a preview in different platforms with potentially different look and feel. [Sweden intends to test this hypothesis in the second iteration of the Moving Abroad Pilot.] [The Studying Abroad Pilot intends to pilot this] This means that the eProcedure should provide the eProcedure Save and Resume service as defined in Procedure Management.	User needs to authenticate only once at the Data Provider. Data Provider offers Preview for all canonical evidences at the same time. Note: Require further, domain specific analysis of legal implications of aggregating evidences types under control by different legal domains. This might result that for some evidence types, separate Evidence Request and Evidence Response Messsages, including an additional Authentication. [The Studying Abroad Pilot intends to pilot this]	User previews all canonical evidences at the same time. The user can select only a subset of evidences for transfer to the Data Consumer. [The Studying Abroad Pilot intends to pilot this, i.e. Portugal is interested in piloting this. Prerequisite is finding students to participate.]	The multiple-subject case (i.e. parent with children) requires a separate record matching for the representation register. We expect that this can be done appropriately, based on the matched record or the user (i.e. parent) and the combination of first name, last name and date of birth of the dependent (i.e. child). [Sweden will probably not Pilot this in the second iteration of the Moving Abroad Pilot]
Working Hypothesis for Intermediation	Not applicable for DE4A	Not applicable for DE4A	Not applicable for DE4A	Not applicable for DE4A
Working Hypothesis for VC	If Data Providers (Issuers) are not highly integrated on MS-level, then the users need to re-authenticate on several different platforms and establish DID connection with different SSI Authority agents. Note: For the VC pattern the multi-evidence case is not an issue as the user would load multiple evidences in his/her wallet and show the evidence(s) when needed.	[Not planned to be used in Studying Abroad pilot]	[Not planned to be used in the pilot]	[Not planned to be used in Studying Abroad pilot]

Stateless DE4A Connector

Business Processes are either Stateless or Stateful, depending on the transactions contained in the process.

Stateless: a stateless process or application can be understood in isolation. There is no stored knowledge of or reference to past transactions. Each transaction is made as if from scratch for the first time.

Stateful applications and processes, however, are those that can be returned to again and again, i.e. keeps track of the state of interaction. Stateful processes are intended to support business scenarios that involve complex, long-running logic and therefore have specific reliability and recovery requirements.

With respect to cross-border exchange of evidence in the context of the OOP Technical System there are complex cases where state needs to be maintained in between sessions. Examples include multiple DPs, multi-evidence, delay in digitising evidence, extensive input from the user required etc. It won't be feasible or is impracticable to perform this in one user session. Also see topic 3.

The main purpose of the DE4A Connector however is to:

- shield business parties from the complexity of using eDelivery and the information desk

- facilitating integration in MSs

- addressing the different roles DE/DR (DC) end DT/DO (DP) which might be performed by different entities.

Irrespective of whether a business process is stateful or stateless, in our view the state should not be maintained in the connector. Instead, this is on the DC/DP for doing so if needed.

Highly Distributed, Cross-border System

D1.7 Legal, technical, cultural and managerial risks and barriers identified 'Administrative Complexity / Organisational silos' and 'Different OOP levels in other EU MS' as two of the main barriers for cross-border once-only. This points to the formidable integration challenge posed by the level of complexity that needs to be managed for a European cross-border, cross-domain Once-Only system to function properly: Integrating across 27 highly heterogenous national eGovernment architectures, administrative systems and legal frameworks.

This is not a typical Enterprise Application Integration (EAI) effort, it is orders of magnitude more complex, encompassing hundreds of organisations and thousands of applications in each of the 27 member states. As a consequence, best practices and architecture principles from EAI must be treated with caution, as they are not equally applicable for such highly distributed systems. Even simple things like maintaining case-specific single attribute correlation IDs can require changes in thousands of systems and interfaces.

In the DE4A architecture, we are constantly trying to balance "common EAI sense" with the subsidiarity principle and a 'minimal impact on MS systems'-approach in an attempt to follow up on two of the main findings of D1.7:

• cross-border digitisation should build upon national digitalisation efforts.
• that digitisation initiatives should have a positive return on investment.

With 27 national architectures in the mix, every assumption about their functioning, structure, ease of integration, used technology etc. is essentially wrong by definition, because at least one MS will be different. This is even true for the implementation of European building blocks - no, not all eIDAS-nodes are the same, they are mildly similar at best. Minimal assumptions about the national systems and an attempt to couple them as loosely as possible goes beyond defining clear interfaces, because these very interface requirements can have significant implications on national level: A mandatory cross-border correlation ID for example might already have significant impact that is disproportional to using concatenate keys to correlate request and response. The assumption that a platform can provide a static URL that is stable over time or that can accept a specific parameter might not hold for all eProcedure portals, as does the assumption that a portal can provide a case-specific URL; hence the solution should be able to deal with both.