Interdisciplinary Questions - Revision history

Ictu alexander.bielowski: /* Multi-evidence Cases */

2021-11-11T12:33:16Z

Multi-evidence Cases

Fredrik.linden: typos and some few wordings

2021-11-10T09:27:40Z

typos and some few wordings

Show changes

Ictu harold.metselaar: /* Multi-evidence Cases */

2021-10-21T11:25:40Z

Multi-evidence Cases

Ictu harold.metselaar: /* Multi-evidence Cases */

2021-10-21T11:23:35Z

Multi-evidence Cases

Ictu harold.metselaar: /* Multi-evidence Cases */

2021-10-21T11:22:56Z

Multi-evidence Cases

Ictu alexander.bielowski: /* Multi-evidence Cases */

2021-09-09T08:17:34Z

Multi-evidence Cases

Ictu alexander.bielowski: /* Highly Distributed, Cross-border System */

2021-07-06T12:40:08Z

Highly Distributed, Cross-border System

Ictu alexander.bielowski: /* Highly Distributed, Cross-border System */

2021-07-06T12:25:12Z

Highly Distributed, Cross-border System

Ictu alexander.bielowski: /* Stateless DE4A Connector */

2021-07-06T12:23:45Z

Stateless DE4A Connector

Ictu alexander.bielowski: /* Multi-evidence Cases */

2021-07-06T12:15:03Z

Multi-evidence Cases

@@ Line 170: / Line 170: @@
 |-
 |Working Hypothesis for [[Intermediation Pattern|Intermediation]]
+|Not applicable for DE4A
+|Not applicable for DE4A
+|Not applicable for DE4A
+|Not applicable for DE4A
 |-
 |Working Hypothesis for [[Verifiable Credentials Pattern|VC]]

@@ Line 177: / Line 177: @@
 |Working Hypothesis for [[Verifiable Credentials Pattern|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 [[Authority Agent|SSI Authority agents]].
 |[Not planned to be used in [[Studying Abroad Pilot|Studying Abroad pilot]]]
-|[tbd. if this case will be covered by the pilots]
+|[Not planned to be used in the pilot]
 |[Not planned to be used in [[Studying Abroad Pilot|Studying Abroad pilot]]]
 |}

@@ Line 167: / Line 167: @@
-''[Sweden will probably not PIlot this in the second iteration of the [[Movin Abroad pilot|Moving Abroad pilot]]]''
+''[Sweden will probably not Pilot this in the second iteration of the [[Moving Abroad Pilot]]]''
 |-
 |Working Hypothesis for [[Intermediation Pattern|Intermediation]]

@@ Line 147: / Line 147: @@
 ''[Sweden intends to test this hypothesis in the second iteration of the [[Moving Abroad Pilot]].]''
@@ Line 154: / Line 157: @@
 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.
 |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 [[Movin Abroad pilot|Moving Abroad pilot]]]''
+''[Sweden will probably not PIlot this in the second iteration of the [[Movin Abroad pilot|Moving Abroad pilot]]]''
 |-
 |Working Hypothesis for [[Intermediation Pattern|Intermediation]]

@@ Line 160: / Line 160: @@
 ''[Sweden intends to test this hypothesis in the second iteration of the [[Movin Abroad pilot|Moving Abroad pilot]]]''
 |-
 |Working Hypothesis for [[Verifiable Credentials Pattern|VC]]

← Older revision		Revision as of 12:40, 6 July 2021
Line 197:		Line 197:
	* that digitisation initiatives should have a positive return on investment.		* 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.	+	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.

@@ Line 190: / Line 190: @@
 [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_c67cf3f7cdf943a48cf8c14c8b1bf36f.pdf 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 to typical Enterprise Application Integration (EAI) effort, it is orders of magnitude more complex, encompassing hundreds of organisation 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.
+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 [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_c67cf3f7cdf943a48cf8c14c8b1bf36f.pdf D1.7]:

@@ Line 185: / Line 185: @@
 - 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.
+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 ==

@@ Line 125: / Line 125: @@
 |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 [[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).
 |-