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 each of the interdisciplinary questions relevant for that specific pattern. This helped to contrast the pattern and make the implications of each of them comprehensible, specifically for policy stakeholders.

[ToDo: add and update the questions from D2.4]

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.

There are three 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
Desrcription	Multiple Data Providers, either one or several evidence types for the same subject (one user = single subject)	Single Data Provider, muliple evidences of differnt type 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 subject (one user, multiple subjects)
Example	Example from Moving Abroad Pilot: For change of adres, several evidence types are required, such as place residence, pension claims, income, which are for most MS issued by diferent Data Providers.	Example from Moving Abroad Pilot: In some MS (i.e. ES), 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. [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 forIntermediation
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.			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).
Working Hypothesis for VC