Current status of pilot - Revision history

Ard.vanderheijden: /* 2.3 Achieved interoperability status */

2022-02-10T15:26:40Z

2.3 Achieved interoperability status

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-10T15:26:09Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-10T15:25:54Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.1.2 Piloting environments */

2022-02-10T15:24:57Z

2.1.2 Piloting environments

Ard.vanderheijden: /* 2.1 Catalogue of services and status */

2022-02-10T15:24:35Z

2.1 Catalogue of services and status

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-09T12:56:34Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-09T11:29:53Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-09T11:28:50Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.2 Strategy to mitigate infrastructure delays */

2022-02-09T11:28:29Z

2.2 Strategy to mitigate infrastructure delays

Ard.vanderheijden: /* 2.1.1 Use cases and pilot scenarios */

2022-02-03T13:37:12Z

2.1.1 Use cases and pilot scenarios

@@ Line 159: / Line 159: @@
 ==2.3 Achieved interoperability status==
-<span style="color:red">Taking the remaining Data Owners and Data Evaluators in to account, several DE/DO combinations remain suitable for piloting.</span> The table below displays the interoperability status for the OOP TS domain, while the second table displays the eIDAS interoperability status between participating Member States.
+Taking the remaining Data Owners and Data Evaluators in to account, several DE/DO combinations remain suitable for piloting. The table below displays the interoperability status for the OOP TS domain, while the second table displays the eIDAS interoperability status between participating Member States.
 {| class="wikitable" style="width: 60%;"
 |+
@@ Line 250: / Line 250: @@
 * The tables above display the connectivity status as established in January 2021. The situation is all but static, and connectivity is being extended continuously so tables may not represent the actual situation when reading this document at a later moment.
 * Sweden
-** is aiming to pilot with a simulated Data Owner, providing fictitious data. Sweden will therefore not pilot with Data Evaluators that offer a <span style="color:red">real eProcedure portal </span>, being Austria and The Netherlands.
+** is aiming to pilot with a simulated Data Owner, providing fictitious data. Sweden will therefore not pilot with Data Evaluators that offer a real eProcedure portal, being Austria and The Netherlands.
 ** does not have a Data Owner (Data Service) fully available for testing yet.
 ** does not have an eIDAS pilot node available yet.

@@ Line 153: / Line 153: @@
 *Wherever possible, already available infrastructure (components) will be reused. These components probably need some adaption in order to be fit for DE4A use, but it often saves time compared to developing a completely new component. For example: The Netherlands managed to use available piloting environments to deploy the DE4A Connector and additional components to interact with the Data Owner.
-*In situations where certain components or services that are needed to test, are not available, these were circumvented temporarily to continue with testing and development. The example of Sweden mimicking the authentication temporarily was already provided. <span style="color:red">Another example is a situation a temporary fictitious Dutch Identity Provider was used in the Dutch eIDAS pilot infrastructure. </span>This allowed testing of all other components in the infrastructure to take place, and secure progress.
+*In situations where certain components or services that are needed to test, are not available, these were circumvented temporarily to continue with testing and development. The example of Sweden mimicking the authentication temporarily was already provided. Another example is a situation a temporary fictitious Dutch Identity Provider was used in the Dutch eIDAS pilot infrastructure. This allowed testing of all other components in the infrastructure to take place, and secure progress.
 *The use of a playground proved to be of major importance to secure progress. The DE4A playground consists of DE4A Connectors, Data Owner mocks and Data Evaluator mocks. These can be used by Data Evaluators and Data Owners in Member States, for development and testing purposes. This way, the can ensure that the integration to the connector actually works before cross border testing starts with real DE4A infrastructure. Also, it makes it possible for Data Evaluators and Data Owners to start development and integration, even before DE4A Connector components actually are available in their countries. They can use the playground components instead, while the national infrastructure is being developed. It proved recommendable to have the playground extensively tested, demonstrated and documented before Member States start using it for development and testing purposes.
 *Establishment of a Minimum Viable Product (MVP) definition turned out to be very important to create focus and manage expectations. By explicitly aiming for a minimum viable product, all partners were forced to focus on what the pilot is really about, but also on what is really feasible. An MVP definition reduced unnecessary discussion of topics that are out-of scope, or turned out to be of minor importance. The MVP definition for both iteration 1 and 2 have been established.

@@ Line 139: / Line 139: @@
 The customization and integration phase for the first pilot iteration has faced some delays, pushing the start of the pilot running phase backwards. Explanations for these delays are:
-* <span style="color:blue">The implementation of the SDG principles touches on many complex and innovative challenges, which require more time than expected. </span>
+* The implementation of the SDG principles touches on many complex and innovative challenges, which require more time than expected.
 * Member States prioritized COVID-19 related activities above DE4A activities, resulting in less resources for DE4A activities.
 * The DE4A common components were available later than expected, so deployment and integration on national level could started later.
@@ Line 147: / Line 147: @@
 Despite the delay, the preparations of the second pilot iteration have started according to planning. Because the activities for iteration 1 are still in progress, this puts pressure on the preparations for the second iteration. The following measures have been taken (and will be taken) to prevent further delays for the second iteration.
-* The infrastructure basically exists of two parts: eIDAS related infrastructure and Once Only Principle related infrastructure. The Data Consumer and Data Provider integrate to these infrastructures and establish cross border connections and exchange information. The OOP TS infrastructure is related strongly to the SDG and is meant for exchanging company-evidence, while the eIDAS infrastructure is a pre-requisite to work with DE systems and the OOP TS at all. In cases where the eIDAS infrastructure has not been completed but the OOP TS infrastructure is ready, the possibility to simulate authentication and authorization will be considered. By mimicking these processes and providing functionality to manually enter a company ID (eIDASLegalIdentifier), it becomes possible to pilot with the OOP TS infrastructure only, albeit in a simulated piloting environment (and not a <span style="color:red">real eProcedure portal or data service offering real data </span>). This approach allows for gaining knowledge of and experience with working with the OOP TS.
+* The infrastructure basically exists of two parts: eIDAS related infrastructure and Once Only Principle related infrastructure. The Data Consumer and Data Provider integrate to these infrastructures and establish cross border connections and exchange information. The OOP TS infrastructure is related strongly to the SDG and is meant for exchanging company-evidence, while the eIDAS infrastructure is a pre-requisite to work with DE systems and the OOP TS at all. In cases where the eIDAS infrastructure has not been completed but the OOP TS infrastructure is ready, the possibility to simulate authentication and authorization will be considered. By mimicking these processes and providing functionality to manually enter a company ID (eIDASLegalIdentifier), it becomes possible to pilot with the OOP TS infrastructure only, albeit in a simulated piloting environment (and not a real eProcedure portal or data service offering real data . This approach allows for gaining knowledge of and experience with working with the OOP TS.
 * In cases where integration activities with DE/DO systems proves difficult due to resource or organizational challenges, the development outside/around these systems can be explored. By choosing this approach, the dependency of limited resources was reduced. Sweden for example, using an eIDAS pilot node proved difficult because of limited resources with the organization that would provide this. As a result, a new eIDAS pilot node is being set up by Bolagsverket.
+*
@@ Line 156: / Line 156: @@
 *The use of a playground proved to be of major importance to secure progress. The DE4A playground consists of DE4A Connectors, Data Owner mocks and Data Evaluator mocks. These can be used by Data Evaluators and Data Owners in Member States, for development and testing purposes. This way, the can ensure that the integration to the connector actually works before cross border testing starts with real DE4A infrastructure. Also, it makes it possible for Data Evaluators and Data Owners to start development and integration, even before DE4A Connector components actually are available in their countries. They can use the playground components instead, while the national infrastructure is being developed. It proved recommendable to have the playground extensively tested, demonstrated and documented before Member States start using it for development and testing purposes.
 *Establishment of a Minimum Viable Product (MVP) definition turned out to be very important to create focus and manage expectations. By explicitly aiming for a minimum viable product, all partners were forced to focus on what the pilot is really about, but also on what is really feasible. An MVP definition reduced unnecessary discussion of topics that are out-of scope, or turned out to be of minor importance. The MVP definition for both iteration 1 and 2 have been established.
-*For the second iteration, the Subscription and Notification pattern will be piloted. A DBA solution architecture is available, detailing the Project Start Architecture to a more detailed prescription for implementing this interaction pattern. The implementation consists of both common components and national components. For the second iteration, certain common components (the 'subscription system' and the 'cross border event handler') are common for all Data Owners, but will not be available as a common DE4A component. In order to pilot, Data Owners that do not have similar components already available on a national level, need to develop something themselves. <span style="color:red"> In these cases (like in The Netherlands), functionality will be developed on a national level, in a fit-for-use fashion. </span>
+*For the second iteration, the Subscription and Notification pattern will be piloted. A DBA solution architecture is available, detailing the Project Start Architecture to a more detailed prescription for implementing this interaction pattern. The implementation consists of both common components and national components. For the second iteration, certain common components (the 'subscription system' and the 'cross border event handler') are common for all Data Owners, but will not be available as a common DE4A component. In order to pilot, Data Owners that do not have similar components already available on a national level, need to develop something themselves. In these cases (like in The Netherlands), functionality will be developed on a national level, in a fit-for-use fashion.
 ==2.3 Achieved interoperability status==

@@ Line 133: / Line 133: @@
 <u>'''Remarks:'''</u>
-* The Swedish and Romanian Data Evaluator eProcedure portals are available in simulated portals and may be upgraded to <span style="color:red">real eProcedure portals </span> later in 2022.
+* The Swedish and Romanian Data Evaluator eProcedure portals are available in simulated portals and may be upgraded to real eProcedure portals  later in 2022.
-* Data Owners providing fictitious data will not pilot with Data Evaluators offering real procedures, to prevent fictitious data contaminating <span style="color:red">real eProcedure portals. </span>
+* Data Owners providing fictitious data will not pilot with Data Evaluators offering real procedures, to prevent fictitious data contaminating real eProcedure portals.
 == 2.2 Strategy to mitigate infrastructure delays ==

@@ Line 22: / Line 22: @@
 * The methods of validating the powers of the representative will be implemented as designed: in the first iteration powers validation will be based on the representative having full powers, while in the second iteration fine grained powers validation is added, allowing companies to differentiate in the procedures the representatives may apply for.
-Doing Business Abroad partners participate with Data Owners (DO) and Data Evaluators (DE), allowing to pilot these use cases in multiple DE/DO combinations. Unfortunately, the partners Skatteverket (Sweden) and BOSA (Belgium) had to terminate their involvement in the DE4A Consortium due to <span style="color:red">other priorities</span>. The table below displays the  DE/DO combinations per use case that will be piloted with the remaining partners, and the current status of their infrastructure (green = ready; yellow = not completely ready)
+Doing Business Abroad partners participate with Data Owners (DO) and Data Evaluators (DE), allowing to pilot these use cases in multiple DE/DO combinations. Unfortunately, the partners Skatteverket (Sweden) and BOSA (Belgium) had to terminate their involvement in the DE4A Consortium due to other priorities. The table below displays the  DE/DO combinations per use case that will be piloted with the remaining partners, and the current status of their infrastructure (green = ready; yellow = not completely ready)
 {| class="wikitable"
 ! rowspan="2" |