Current status of pilot

[Work in progress]

2.1 Catalogue of services and status

2.1.1 Use cases and pilot scenarios

Previous deliverables already defined the two use cases and six pilot scenarios for the DE4A Doing Business Abroad pilot. During the customization and integration phase for the first pilot iteration these have been refined (and is some cases were abandoned due to pilot partners having to leave the consortium):

Use case 1: starting a business in another Member State
- the core of this use case is the fulfilment of procedural obligations to start doing business in the Member State. Therefore the pilot concentrates on the steps for a business to register with a service provider abroad.

Use case 2: doing business in another Member State
- the core of this use case is retrieving and updating company information by the service provider / processing business events. Therefore the pilot focuses on the subscription process and the process of sending, receiving and processing event notifications

Please note:

The option to fulfil corporate tax duties or apply for a service may still be possible with the service provider, but will not be piloted.
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 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)

	Data consumer			UC-1 Starting a business in another Member State				UC-2 Doing business in another Member State
	Data consumer			Data Owner				Data Owner
pilot scenario	Country	Name	Portal	AT	NL	RO	SE	AT	NL	RO	SE
DBA1	Austria	BMDW	USP.gv.at		KvK	ONRC	BVK		N/A	N/A	N/A
DBA4	The Netherlands	RVO	mijn.rvo.nl	BMDW		ONRC	N/A	N/A		ONRC	BVK
DBA5	Romania	ONRC	portal.onrc.ro	BMDW	KvK		BVK	N/A	KvK		BVK
DBA6	Sweden	BVE	verksamt.se	BMDW	KvK	ONRC		N/A	KvK	ONRC

Data Owners and Data Evaluators have completed the deployment of, and the integration with the OOP TS components without any irregular challenges or issues. This achievement benefits both iteration 1 and 2 and is therefore of great importance.

Data Owners and/or Data Evaluators being not completely ready for Use Case 1 (which is piloted in the first iteration) is due to eIDAS related issues:

The establishment of the Swedish eIDAS pilot node is still in progress.This is expected to complete by Q1 2022. Because the Swedish eProcedure portal (verksamt.se) cannot use an eIDAS pilot node yet, the portal is temporarily equipped with a simulated authentication and authorization mechanism without eIDAS. This allows the portal to be used for piloting and gaining experience on working with the DE4A infrastructure.
The eIDAS connection has not yet been established between available eIDAS pilot nodes of
- Austria and The Netherlands. This is expected to be completed by Q2 2022.
- Austria and Romania. This is expected to be completed by Q2 2022.
The integration of the Austrian eIDAS pilot node and the Austrian Data Evaluator portal can not be established before March 2022.

2.1.2 Piloting environments

DBA partners have prepared data services (DO) and eProcedure portals (DE) for piloting. The possibilities in each country to set up environments differ, mainly due tot national or local legal constraints. Not all partners / Member States were allowed for piloting real procedures using SDGR-oriented solutions prior to the SDGR coming into effect. The table below displays the situation per partner:

	DO Data Source	DE eProcedure portal
Sweden	provides fictitious data	offers simulated procedure
Romania	provides real data	offers simulated procedure
Austria	provides real data	offers real procedure
The Netherlands	provides real data	offers real procedure

Remarks:

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 real eProcedure portals.

2.2 Strategy to mitigate infrastructure delays

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:

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.
Deployment of, and integration to the DE4A components is often performed by several organizations within Member States. This requires more time to align and coordinate, and has proven to be reason for misunderstandings and discussions. National organizations that pilot partners collaborate with, seem less committed to the pilot which seems to reduce willingness to apply changes to infrastructural components.
Obtaining certificates for secure piloting proved to take a long time.

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 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.

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. 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.
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

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.

Interoperability status between Data Owners an Data Evaluators, using the OOP TS
	MS acting as DP
		AT	NL	RO	SE
MS acting as DC	AT				N/A
	NL				N/A
	RO
	SE

Interoperability status on eIDAS pilot nodes between DBA partners
	Proxy
		AT	NL	RO	SE
Connector	AT
	NL
	RO
	SE

Green = Connection established and confirmed

Yellow = Connection partially established and confirmed

Red = Connection not established or confirmed

Remarks:

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 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.
Austria
- Has a first opportunity to integrate the Austrian eIDAS pilot node to the eProcedure portal by March 2022. After that, connections with NL and RO can be tested and confirmed.
- Has an eIDAS node implementation available that differs from the Dutch/Romanian implementation. For the second iteration adjustments are made to ensure connectivity between these nodes and allow for piloting.

2.4 Updates in Metrics

The pilot goals, success criteria and metrics as defined in the previous deliverable (D4.6 Pilot Planning) remain the same.

As the customization and integration phase for the second iteration progresses, minor adjustments in metrics are expected to be introduced.

Next chapter: 3. Goals and success criteria