MA Solution Architecture - Revision history

Fredrik.linden at 11:45, 14 February 2023

2023-02-14T11:45:56Z

Fredrik.linden at 08:39, 7 February 2022

2022-02-07T08:39:52Z

Fredrik.linden at 07:54, 9 December 2021

2021-12-09T07:54:30Z

Patrick.oberg at 14:10, 28 September 2021

2021-09-28T14:10:19Z

Patrick.oberg at 14:09, 28 September 2021

2021-09-28T14:09:01Z

Patrick.oberg: /* Design Choices */

2021-09-28T14:07:24Z

Design Choices

Patrick.oberg: Created page with "=== Introduction === The solution architecture for the Moving Abroad (MA) pilot has been constructed in close cooperation with WP2 to ensure full alignment to the DE4A archite..."

2021-09-28T14:02:17Z

Created page with "=== Introduction === The solution architecture for the Moving Abroad (MA) pilot has been constructed in close cooperation with WP2 to ensure full alignment to the DE4A archite..."

New page

=== Introduction ===
The solution architecture for the Moving Abroad (MA) pilot has been constructed in close cooperation with WP2 to ensure full alignment to the DE4A architecture. Its purpose is to guide the design and development of (adaptions to) required components by the pilot participants and to assist the ongoing cooperation and alignment with WP3 for semantics and WP5 for software components.

The solution architecture presented in this document is guided by several aspects of previous work, like D4.3 and D2.4. This previous work defines scope, working assumptions, preconditions, areas of interest, design choices, etc. Not all of these have been copied into this document. This chapter highlights only the most important ones, without aiming to be complete. Please refer to those documents for more information on the MA pilot.

This document specifies the SA solution architecture. Its purpose is to assist the design of the software architecture and development and configuration of the components needed:

* By WP5 and WP3 for the common components.
* By the DCs for their specific application services, like the eProcedure portal and connection to the OOP TS (i.e. DE4A TS) and eIDAS.
* By the DPs for their specific application services, like the Evidence portal, data services and connection to the OOP TS and eIDAS.

==== Scope & Focus ====
The scope of this architecture is limited to the minimum viable product (MVP 1.0) that has been defined by the partners of the MA pilot. The second pilot run is out of scope of this version of the solution architecture. Furthermore:

* The MVP 1.0 implements the smallest possible functionality needed to run the MA pilots for the first use case (request change of adress), although it is also applicable to the second use case (request extract of civil certificate), as both use cases plan to implement the same interaction pattern. All components that do not directly contribute to the MVP 1.0 are out of scope for this architecture.

* This solution architecture applies to the user-supported intermediation pattern only, relevant for the MA UC#1 and UC#2.
* The solution to implement should be production-worthy as the goal of the MA pilot is to pilot in a production environment.

In the MVP 1.0 the MA pilot will use just one type of evidence and there will be just one data provider per member state and the DC will request just one member state for the evidence.

==== Business Requirement ====
The intent of the project DE4A is to run a number of pilots in production to prove that selected/adapted building blocks from other projects in the European Community [AC1] [PÖ2] and new components developed by the DE4A can be combined to achieve business value to the user in respect to the Once-Only Principle and the Single Digital Gateway regulation.

The business requirements of the Moving Abroad pilot planned for 2021 is clear; it must be possible for a user through the support of Competent Authorities [AC3] [PÖ4] to request, preview and receive evidences[AC5] [PÖ6] , in the specified cross-border scenarios and use cases, in order to create real business value to the users.

This document describes the solution architecture of how these business requirements can be met and how the expected business value can be achieved.

==== Preconditions ====
The MA solution architecture implements some DE4A-wide decisions:

* The OOP TS consists of functionality for evidence exchange as well as the information desk. DE4A uses eDelivery for implementing the evidence exchange functionality. Other options for messaging have not been considered in constructing this solution architecture.
* DE4A uses eIDAS regular nodes. Early adopters Other options have not been considered in constructing this solution architecture.

The following preconditions has been identified and described by the early adopters of the first iteration of the MA pilot, MVP 1.0

* Existing eProcedures requires development to make use of the cross border information exchange
* eIDAS nodes currently running in production
* No support for non-notified eIDAS
* eDelivery is in varying stages of implementation by member states and will at a minimum require configuration
* Existing eProcedures are to some extent interrupted in behaviour but will likely need some stabilizing development
* Existing eProcedures will follow the general flow described by the solution architecture but variations are to be expected
* Preview of evidence will be done in domestic form
* The received evidence will be used in subsequent interaction with the user
* National eID will be required to preview evidence and to some extent notified eIDAS will also be supported
* The eProcedure will be completed online but the completion of the registration process varies between member states, including:
*# Verification of physical presence in the country
*# Verification by postal mail
*# Completed online

==== Design Choices ====
The MA pilot partners made several choices in implementing the MA pilots:

* The MA pilot uses the eIDAS mandatory personal data set to communicate the user identity information. DPs may request for additional attributes needed for record matching. As MVP 1.0 will only cover two-country scenarios, the user can also use their national identities for authenticating at the DP if supported by national central identity management system.
* The MA pilot will use the OOP TS for retrieving the citizen data needed for the eProcedure.
* The MA pilot will use existing eIDAS nodes in the participating member states.

@@ Line 6: / Line 6: @@
 This document specifies the SA solution architecture. Its purpose is to assist the design of the software architecture and development and configuration of the components needed:
-* By WP5 and WP3 for the common components.
+* By WP5 and WP3 for the common components including De-registration.
 * By the DCs for their specific application services, like the eProcedure portal and connection to the OOP TS (i.e. DE4A TS) and eIDAS.
 * By the DPs for their specific application services, like the Evidence portal, data services and connection to the OOP TS and eIDAS.
@@ Line 66: / Line 66: @@
 * Shared solution: the common part of the solution.
-* The application services that are common to the MA pilot. These are typically the application services that are part of the Once Only Technical System (OOP TS) and eIDAS. The MA pilot expects WP3 and WP5 to select, design and develop the components needed for these common application services. These components need to be deployed and configured by each of the piloting member state.
+* The application services that are common to the MA pilot. These are typically the application services that are part of the Once Only Technical System (OOP TS) and eIDAS. The MA pilot expects WP3 and WP5 to select, design and develop the components needed for these common application services. These components need to be deployed and configured by each of the piloting member states.
 * DC-specific solution: the part of the solution the DC has to implement.
 * DP-specific solution: the part of the solution the DP has to implement.
 The eIDAS network is – from the OOP TS – a separate network of eIDAS nodes and their connections. It is linked to the OOP TS via the data consumer that coordinates the eProcedure portal and the data provider that coordinates the Evidence portal.

← Older revision		Revision as of 14:07, 28 September 2021
Line 55:		Line 55:
	* The MA pilot will use the OOP TS for retrieving the citizen data needed for the eProcedure.		* The MA pilot will use the OOP TS for retrieving the citizen data needed for the eProcedure.
	* The MA pilot will use existing eIDAS nodes in the participating member states.		* The MA pilot will use existing eIDAS nodes in the participating member states.
		+
		+	==== eIDAS & OOP TS ====
		+	The MA pilot implements the reference processes of the DE4A’s project start architecture to meet the requirement of the MA pilot. In designing the solutions for the processes, MA distinguishes between the:
		+
		+	eIDAS solution architecture: The architecture for using eIDAS to authenticate the natural person.
		+
		+	OOP TS solution architecture: The architecture for using the OOP TS for exchange of citizen data between the data consumer and the data provider.
		+
		+	The solution architectures is divided in:
		+
		+	* Shared solution: the common part of the solution.
		+	* The application services that are common to the MA pilot. These are typically the application services that are part of the Once Only Technical System (OOP TS) and eIDAS. The MA pilot expects WP3 and WP5 to select, design and develop the components needed for these common application services. These components need to be deployed and configured by each of the piloting member state.
		+	* DC-specific solution: the part of the solution the DC has to implement.
		+	* DP-specific solution: the part of the solution the DP has to implement.
		+
		+	The eIDAS network is – from the OOP TS – a separate network of eIDAS nodes and their connections. It is linked to the OOP TS via the data consumer that coordinates the eProcedure portal and the data provider that coordinates the Evidence portal.

@@ Line 2: / Line 2: @@
 The solution architecture for the Moving Abroad (MA) pilot has been constructed in close cooperation with WP2 to ensure full alignment to the DE4A architecture. Its purpose is to guide the design and development of (adaptions to) required components by the pilot participants and to assist the ongoing cooperation and alignment with WP3 for semantics and WP5 for software components.
-The solution architecture presented in this document is guided by several aspects of previous work, like D4.3 and D2.4. This previous work defines scope, working assumptions, preconditions, areas of interest, design choices, etc. Not all of these have been copied into this document. This chapter highlights only the most important ones, without aiming to be complete. Please refer to those documents for more information on the MA pilot.
+The solution architecture presented is guided by several aspects of previous work, like D4.3 and D2.4. This previous work defines scope, working assumptions, preconditions, areas of interest, design choices, etc. Not all of these have been copied into this document. This chapter highlights only the most important ones, without aiming to be complete. Please refer to those documents for more information on the MA pilot.
 This document specifies the SA solution architecture. Its purpose is to assist the design of the software architecture and development and configuration of the components needed:
@@ Line 11: / Line 11: @@
 == Scope & Focus ==
-The scope of this architecture is limited to the minimum viable product (MVP 1.0) that has been defined by the partners of the MA pilot. The second pilot run is out of scope of this version of the solution architecture. Furthermore:
+The scope of this architecture is limited to the minimum viable product (MVP 1.0) that has been defined by the partners of the MA pilot.
-* The MVP 1.0 implements the smallest possible functionality needed to run the MA pilots for the first use case (request change of adress), although it is also applicable to the second use case (request extract of civil certificate), as both use cases plan to implement the same interaction pattern. All components that do not directly contribute to the MVP 1.0 are out of scope for this architecture.
+* The MVP 1.0 implements the smallest possible functionality needed to run the MA pilots for the first use case (request change of address), although it is also applicable to the second use case (request extract of civil certificate), as both use cases plan to implement the same interaction pattern. All components that do not directly contribute to the MVP 1.0 are out of scope for this architecture.
 * This solution architecture applies to the user-supported intermediation pattern only, relevant for the MA UC#1 and UC#2.
@@ Line 31: / Line 31: @@
 * The OOP TS consists of functionality for evidence exchange as well as the information desk. DE4A uses eDelivery for implementing the evidence exchange functionality. Other options for messaging have not been considered in constructing this solution architecture.
-* DE4A uses eIDAS regular nodes. Early adopters Other options have not been considered in constructing this solution architecture.
+* DE4A uses eIDAS regular nodes. Early adopters may use other options but that has not been considered in constructing this solution architecture.
 The following preconditions has been identified and described by the early adopters of the first iteration of the MA pilot, MVP 1.0
@@ Line 39: / Line 39: @@
 * No support for non-notified eIDAS
 * eDelivery is in varying stages of implementation by member states and will at a minimum require configuration
-* Existing eProcedures are to some extent interrupted in behaviour but will likely need some stabilizing development
+* Existing eProcedures are to some extent interrupted in behavior but will likely need some stabilizing development
 * Existing eProcedures will follow the general flow described by the solution architecture but variations are to be expected
 * Preview of evidence will be done in domestic form
@@ Line 45: / Line 45: @@
 * National eID will be required to preview evidence and to some extent notified eIDAS will also be supported
 * The eProcedure will be completed online but the completion of the registration process varies between member states, including:
-*# Verification of physical presence in the country
+*# Verification of physical presence in the country (but then with all evidences cleared and ready).
 *# Verification by postal mail
 *# Completed online

@@ Line 21: / Line 21: @@
 == Business Requirement ==
-The intent of the project DE4A is to run a number of pilots in production to prove that selected/adapted building blocks from other projects in the European Community [AC1] [PÖ2] and new components developed by the DE4A can be combined to achieve business value to the user in respect to the Once-Only Principle and the Single Digital Gateway regulation.
+The intent of the project DE4A is to run a number of pilots in production to prove that selected/adapted building blocks from other projects in the European Community and new components developed by the DE4A can be combined to achieve business value to the user in respect to the Once-Only Principle and the Single Digital Gateway regulation.
-The business requirements of the Moving Abroad pilot planned for 2021 is clear; it must be possible for a user through the support of Competent Authorities [AC3] [PÖ4] to request, preview and receive evidences[AC5] [PÖ6] , in the specified cross-border scenarios and use cases, in order to create real business value to the users.
+The business requirements of the Moving Abroad pilot planned for 2021 is clear; it must be possible for a user through the support of Competent Authorities to request, preview and receive evidences, in the specified cross-border scenarios and use cases, in order to create real business value to the users.
 This document describes the solution architecture of how these business requirements can be met and how the expected business value can be achieved.

@@ Line 1: / Line 1: @@
-=== Introduction ===
+== Introduction ==
 The solution architecture for the Moving Abroad (MA) pilot has been constructed in close cooperation with WP2 to ensure full alignment to the DE4A architecture. Its purpose is to guide the design and development of (adaptions to) required components by the pilot participants and to assist the ongoing cooperation and alignment with WP3 for semantics and WP5 for software components.
@@ Line 10: / Line 10: @@
 * By the DPs for their specific application services, like the Evidence portal, data services and connection to the OOP TS and eIDAS.
-=== Scope & Focus ===
+== Scope & Focus ==
 The scope of this architecture is limited to the minimum viable product (MVP 1.0) that has been defined by the partners of the MA pilot. The second pilot run is out of scope of this version of the solution architecture. Furthermore:
@@ Line 20: / Line 20: @@
 In the MVP 1.0 the MA pilot will use just one type of evidence and there will be just one data provider per member state and the DC will request just one member state for the evidence.
-=== Business Requirement ===
+== Business Requirement ==
 The intent of the project DE4A is to run a number of pilots in production to prove that selected/adapted building blocks from other projects in the European Community [AC1] [PÖ2] and new components developed by the DE4A can be combined to achieve business value to the user in respect to the Once-Only Principle and the Single Digital Gateway regulation.
@@ Line 27: / Line 27: @@
 This document describes the solution architecture of how these business requirements can be met and how the expected business value can be achieved.
-=== Preconditions ===
+== Preconditions ==
 The MA solution architecture implements some DE4A-wide decisions:
@@ Line 49: / Line 49: @@
 *# Completed online
-=== Design Choices ===
+== Design Choices ==
 The MA pilot partners made several choices in implementing the MA pilots:
@@ Line 56: / Line 56: @@
 * The MA pilot will use existing eIDAS nodes in the participating member states.
-=== eIDAS & OOP TS ===
+== eIDAS & OOP TS ==
 The MA pilot implements the reference processes of the DE4A’s project start architecture to meet the requirement of the MA pilot. In designing the solutions for the processes, MA distinguishes between the: