Difference between revisions of "Current status of pilot"
Line 43: | Line 43: | ||
|Austria | |Austria | ||
|BMDW | |BMDW | ||
− | |style="background-color: | + | |style="background-color: lightyellow"|USP.gv.at |
|style="background-color: lightgrey"| | |style="background-color: lightgrey"| | ||
|style="background-color:lightyellow"|KvK | |style="background-color:lightyellow"|KvK | ||
Line 77: | Line 77: | ||
|style="background-color: lightyellow"|KvK | |style="background-color: lightyellow"|KvK | ||
|style="background-color: lightgrey"| | |style="background-color: lightgrey"| | ||
− | |style="background-color: | + | |style="background-color: lightyellow"|BVK |
|- | |- | ||
!DBA6 | !DBA6 |
Revision as of 12:05, 19 January 2022
Back to Doing Business Abroad main page
Back to main page of D4.7 Initial Running Phase Report
Back to previous Chapter: 1. Introduction
2.1 Catalogue of services and status
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. Therefore the pilot will focus on the subscription process and the process of sending, receiving and processing event notifications.
- the option to fulfill corporate tax duties or apply for a service may still be possible with the service provider, but will not be piloted.
It is worth mentioning that the methods of validating the powers of the representative remain unchanged: 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, opening up the possibility to work with representatives having sufficient powers to complet the cross border procedure.
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 Skatteverkes (Sweden) and BOSA (Belgium) had to terminate their involvement in the DE4A Consortium due to - for example - higher priorities caused by establishing the international COVID-19 certificates. 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 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. 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.
- 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.
The Swedish and Romanian Data Evaluator eProcedure portals are available in simulated environments and may be upgraded to production environments later. Because the Swedish eProcedure portal (verksamt.se) cannot use an eIDAS node yet, the portal is temporarily equipped with an simulated authentication and authorization mechanism without eIDAS. This allows the portal to be used for piloting and gaining experience on working with the OOP TS.
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 DE4A common components were available later than expected, so deployment and integration on national level could started later.
- Member States prioritized COVID-19 related activities above DE4A activities, resulting in less resources for DE4A activities.
- COVID-19 required all DE4A collaboration to take place in an online fashion, being less effective than regular face-to-face meetings.
- Deployment of, and integration to the OOP TS 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 OOP TS 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 production environment). 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. For the first iteration this approach was already used in The Netherlands, where an available standard webservice of the Data Owner was used to query and retrieve data on companies, while an external component was developed to act as an intermediator between this DO service and the DE4A Connector (Data Transferrer). This way, requests from the DE4A Connector were translated to requests for the DO webservice and the response of this webservice was translated to the DE4A CompanyEvidence format, by this external component. By choosing this approach, the dependency of limited resources was reduced. Also in Sweden, the use of 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 aughentication temporarily was already provided. Another example is a situation where the Dutch IdentityProvider in the Dutch eIDAS pilotinfrastructure was not available and a simulated IdentityProvider was used for the time being. 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 bth 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 but this will not result in a internationally reusable, fully documented component. Rather, because of time and effort constraints, solutions will be lean and men, aiming to support what is needed to support piloting at a bare minimum.
2.3 Achieved interoperability status
Taking into account that certain DBA partners needed to terminate their involvement in the DE4A Consortium, several Data Owner/DataEvaluator combinations remain. 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.
MS acting as DP | |||||
---|---|---|---|---|---|
AT | NL | RO | SE | ||
MS
acting as DC |
AT | N/A | |||
NL | N/A | ||||
RO | |||||
SE |
Green = Connection established
Yellow = Connection partlially established (issues remaining to be solved)
Red = Connection not established yet
The current status of participating Member States having established connections is displayed in the tables below:
Proxy | |||||
---|---|---|---|---|---|
AT | NL | RO | SE | ||
Connector | AT | ||||
NL | |||||
RO | |||||
SE |
To provide an overview of all possible DE/DO combinations and display the extend to which interoperability is possible
- NL: DO, DT, DR, DE operational; eIDAS operational
- AT: DO, DT, DT operational; DE operational but connected to eIDAS in March 2022; eIDAS operation with version 2.5, profile 1.2
- RO: DO, DT, DR, DE operational (DE=simulated); eIDAS operational
- SE: DO, DT, DR, DE operational (DE/DO simulated); eIDAS operational per January 2022
2.4 Updates in Metrics
To describe (if any) changes in metrics compared to the previous deliverable. Use D4.6 section 2.2 as a basis.
Include explanation about the changes performed and reasons behind.
- no updates?
- Or perhaps, now that we have more knowledge about S&N, Lookup and Fine Grained Powers Validation, we might want to refine the metrics on that?
- Mention that an additional questionnaire (limited in size) will be added, focussing on technical adequacy, process of connecting and deploying, and documentation. Not related to DBA pilot goals or success criteria, but to collect lessons learned for Chapter 3 of D4.7.