Interdisciplinary Questions
The PSA collected 23 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. 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 PD 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.
Multiple, 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. 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.
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 have a mechanism to migrate the requested evidence on demand. Including this possibility would increase the volume of evidence that can be exchanged in the pilots. Also, in the multi-evidence case, when more two or more evidences needs to be collected, it may not be feasible for the user to complete the procedure in one take.
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. At the moment it is not entirely clear 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. DE4A Legal Compliance Work Package has produced a White Paper on ‘Explicit Request’.
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 DP. We should consider the need for a user interface for the once-only technical system that is separate from the eProcedures form itself. DE4A Legal Compliance Work Package has produced a White Paper on ‘Preview of Evidence Exchanged’. Consensus on this point between Member States 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 already reasonably well understood 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 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 Minimal 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 that 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 can differ between Member States and can change over time).
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 same exceptions flow problematic as above applies (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.
Hand-on 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 giving again 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. This is a complexing factor in the identification and OOP exchange of evidence that we cannot ignore. 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]), given among others 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. 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. 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 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 perfectly 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.
Unfortunately, this discussion is often combined 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 required 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 different MS.
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. 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 are fully productive and add real business 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) could also be investigated to alleviate this limitation and to 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, ie. - Request Pension Information & Claim Pension, - both in regard to relevant authorities and to exchanged information. We will need to know early in the MS pilot whether some EESSI capabilities are to be reused. This reuse can reach 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. We will need to understand early in the business pilot whether some BRIS capabilities are to be reused or not in order to move the pilot along. Form and intensity can vary as stated above in section #EESSI integration.
eIDAS and national authentication systems
The question of user authentication in OOP centres around the user 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 a 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; Demark, Netherlands and Slovenia support only eIDAS IN.
Non-notified eIDs
Until now the pilots can only move to production with Member States that notified their eID only. 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, Romania and have not notified yet their identification scheme.
Payment for evidence
Some competent authorities charge fees for retrieving or issuing evidence. Pricing models usually cater for national data consumers, not for cross-border users. This could limit piloting real data in the production environment. 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.
Trust Management
Consistent framework 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 block chain 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 issue is 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).
Legal validity or SSI and block chain technology
There are several legal concerns around the applicability of Self-Sovereign Identity and Block-chain technology, such as the storage of personal data in on distributed ledgers or he validity of a decentral identifier. This led Spain to all but ban blockchain from application in eGovernment. By RDL 14/2019 it is forbidden use a blockchain infrastructure to offer any identification or signature process (until a European or national law regulates the use of these technologies). Presently these questions are not clear and 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 block chain 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 focussed 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.
Fourth, the Once-Only Technical System High Level Architecture is in a 0.3 draft version and allows extensions. Starting with one pattern in 2020 might be a sensible choice, given the challenging timeline until 2023, but it should not be the only choice by design.
Matching evidences between Member States
Evidences that cater for the same or similar life events or public procedures are very heterogenous across MS, as was confirmed by the Deloitte Study on Data Mapping for the cross-border application of the Once-Only technical system SDG [11]. 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 currently working on 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 Producers. 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.
There are four distinct reasons for the Multi-evidence Case to arise.
| 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, muliple 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 Data Owners 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 sources 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.
|
User needs to authenticate only once at the Data Provider. Data Provider offers Preview for all canonical evidences at the same time.
|
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 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 intends to test this hypothesis in the second iteration of the Moving Abroad pilot] |
| 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. | [Not planned to be used in Studying Abroad pilot] | [tbd. if this case will be covered by the pilots] | [Not planned to be used in Studying Abroad pilot] |
Historical Evidence or Evidence History
[discuss in PSALT]
[Question: Could historical evidences be of interest to procedures? For example, previous residency in case of re-migration use cases.]