DBA UC1 major design decisions

From DE4A
Jump to navigation Jump to search

Back to main DBA UC1 page

As part of this project phase, the project team concluded on several important topics. This section presents these topics and the main conclusions. Many details have been left out of this section in order to be to-the-point for this document’s purpose. The details of these topics are part of several project internal documents available on request.

Two Member State intermediation scenario

The DBA pilot will be restricted to the two Member State scenario: one Member State operates as data consumer (hosting the data evaluator and data requestor roles) and one Member State operates as data provider (hosting the data owner and data transferor). Authentication and powers validation takes place in the data providing Member State with an eID of that Member State.

In the first pilot iteration the DBA pilot will implement only the intermediation pattern. After authentication, the user will interact with the data consumer only (more specific: the data evaluator). There will be no user interaction at the data provider / data providing Member State for retrieving the evidence. The previewing of the evidence will be handled by the data evaluator as well.

Real eProcedures and simulated eProcedures

Member States involved in DBA facilitate the pilot in different ways. E.g. some pilot partners will fully integrate the pilot in their real eProcedures and others will use a simulated eProcedure portal. The DBA pilot defined three options for the eProcedure portal:


Simulated eProcedure:

  1. In this scenario the eProcedure will be simulated only. Member States may facilitate this by:
  • Using a test environment for running the pilot, e.g. pre-production.
  • Using a simulated eProcedure portal. Member States using a simulated eProcedure portal will do so in order not to interfere with regular production services. The simulated eProcedure portal will be used for piloting only, without the result of a procedure having any impact on the (software of the) real eProcedure portal.
  1. Real eProcedure:
  • Involving company registration only. In this scenario the Member State pilots the registration of the company into the eProcedure portal’s registry in a live-environment. The company may apply for a follow-up eService, but will not finalise the application. This way, the legal consequences for the company are absent or very limited the least. The Member State can hereby pilot real company registration, even with companies that have no intention to start or do business cross-border. The main advantages of this scenario are the increased possibility to involve real companies in piloting and the absence of procedure-exceptions or extensive data clean-up afterwards by the data evaluator.
  • Including a follow-up eService. In addition to the real company registration at the eProcedure portal (scenario 2), in this scenario the company also successfully applies for, by example, a subsidy, F-tax, or any other service following a successful company registration.


The table below shows the type of eProcedure that will be supported in the first pilot iteration.

MS Pilot scenario eProcedure Portal to pilot (data evaluator role)
 AT USP.gov.at Real eProcedure involving company registration only (2)
 NL MijnRVO.nl Real eProcedure involving company registration only (2)
 RO portal.onrc.ro Simulated eProcedure
 SE Verksamt.se Simulated eProcedure

Real data and fictitious data

When involving real companies, the pilot partners will use real data as well. When using fictitious companies, the DBA pilot uses fictitious data as well.

1.      Fictitious company data: company information regarding a non-existing company.

2.      Real company data: company information regarding an officially registered company.

For piloting, combinations are imaginable, like using fictitious companies and real data. These combinations have not been considered in this deliverable though. Piloting real companies means using real company data. Piloting fictitious companies means piloting with fictitious data.


Simulated eProcedures may accept real users and real data. In case the Member State does not pilot with a real eProcedure (SE and RO), they should accept real users and real data in their simulated eProcedures to meet the DE4A requirements. But, because of the use of real data in a simulated environment, there should be sufficient safeguards to properly protect the companies’ data in the simulated eProcedure. E.g. access to the simulated portal should be restricted. When simulating the eProcedure is just a step-up to pilot real eProcedures, there is no need to accept real users and real data in the simulated procedure (AT and NL). AT and NL will pilot with real eProcedures that – by definition – accept real data. In real eProcedures no fictitious data is accepted.


The table below shows whether the data evaluator accepts real users and real data. Please note, in this table “accept” should read: allow use of real company data provided by other Member States in the eProcedure portal to pilot. E.g. SE will accept real companies and real company data in the simulated eProcedure as data evaluator (although SE will not provide any real company data itself).

MS Pilot scenario Accept fictitious data in portal to pilot (data evaluator role) Accept real data in portal to pilot (data evaluator role)
 AT USP.gov.at No Yes
 NL MijnRVO.nl No Yes
 RO portal.onrc.ro Yes Yes
 SE Verksamt.se Yes Yes


Almost all data owners will provide fictitious company data (1) to start with and real company data (2) for piloting real eProcedures. The table below presents the data that the data owners will provide to data evaluators cross-border. E.g. Sweden provides fictitious company data (and no real data) to the other Member States.

Almost all data owners will provide fictitious company data (1) to start with and real company data (2) for piloting real eProcedures. The table below presents the data that the data owners will provide to data evaluators cross-border. E.g. Sweden provides fictitious company data (and no real data) to the other Member States.

MS Data provider Provide fictitious company data Provide real company data
 AT BMDW Yes Yes
 NL KVK Yes Yes
 RO ONRC Yes Yes
 SE BVE Yes No


Furthermore:

  • The DBA pilot will rely on the national and EU legislation that is already in place for use of identity data (eIDAS) and company data (Service Directive, Company law package, Common agricultural policy, etc.) in the eServices to pilot.
  • The DBA pilot assumes the SDGR provides sufficient legal basis to pilot the OOP technical system with real data in anticipation of (this part of) the SDGR going into effect end of 2023[2]. To confirm this point of view, pilot partners will sign a Memorandum of understanding for cross-border piloting.
  • The DBA pilot will inform the user – as part of the “explicit request” - that the OOP TS will be used for exchange of data before the SDGR is into effect at the moment the initial pilot starts. The user in all cases has the option not to proceed or to use the current in-person procedure for company registration.
  • For AT and NL cases, users should also be informed that there will be no follow-up service so there are no legal consequences of company registration.

eIDAS network and non-notified eIDs

Specific to the DBA pilot, and an important part of the DBA pilot, is the need to validate the powers of the person representing the company and the use of non-notified eIDs. Both aspects require additional eIDAS functionality to include in the pilot.


Dedicated pilot network

In order to support these functionalities while not interfering with the regular eIDAS production, pilot partners will set up a separate pilot network of eIDAS nodes: the dedicated eIDAS pilot network. The dedicated eIDAS pilot nodes are separate from the regular eIDAS nodes in order not to interfere with regular eIDAS use. This approach has explicitly been contemplated in planning milestones and in the Member State pilot management plans.

MS Implement dedicated pilot node Use CEF reference software eIDAS specification to implement
 AT Yes Yes, version 2.4 1.1
 NL Yes Yes, version 2.4 1.1
 RO Yes Yes, version 2.4 1.1
 SE Yes No 1.2

Table 35: Member State overview of eIDAS nodes


The use of national eID in the data consuming Member State (so non-eIDAS authentication) is not relevant for piloting DBA and hence not in scope of the pilot.


Use of eIDASLegalPersonIdentifier

The eIDAS attribute profile [4] defines the attributes to exchange over the eIDAS network. To uniquely identify a company, the attribute profile specifies the eIDASLegalPersonIdentifier. The attribute profile describes the purpose of the attribute and its formatting, but does not prescribe the specific type of identifier to populate the eIDASLegalPersonIdentifier with. A Member State may use for example the EUID (definition by BRIS) as value for the eIDASLegalPersonIdentifier, but may select any other company identifier as well. E.g. NL will use the national Chamber of commerce number (KVK nummer) to identify the company.

An example of an eIDASLegalPersonIdentifier is RO/AT/02735442Z: Romanian Company with company identifier 02735442Z applies for a service in Austria.


For proper record matching at the data owner, the DBA pilot partners agreed to include in the eIDASLegalPersonIdentifier a company identifier that the data owner can use to uniquely find the company involved. E.g. with the KVK number that the NL will provide to the data evaluator in the authentication process, the Dutch KVK can easily find the company involved once it receives a request for this evidence from the data evaluator. More information on record matching has been included in section 3.3.6.


Use of non-notified eID

Most of the participating Member States do not operate an eIDAS-notified eID yet (AT, SE and RO). All participating Member States agreed to accept the non-notified eID for piloting purposes though. The smaller scale piloting as well as the voluntary participation by the companies justify use of non-notified eIDs. By using a dedicated pilot network, pilot partners will connect non-notified eIDs as if they were notified. Use of these non-notified eIDs is – by the nature of the pilot network – restricted to the partners involved in piloting.

Has notified eID eID to use for piloting Type of test credentials to use Level of Assurance[3] Accepts non-notified eID for piloting
 AT No MOA id t.b.d. t.b.d. Yes
 NL Yes eRecognition OTP token / app substantial Yes
 RO No Dedicated IdP t.b.d. t.b.d. Yes
 SE No t.b.d. t.b.d. t.b.d. Yes


Need for powers validation

The DBA pilot requires not only the identification of the company, but also the validation of the user’s powers to represent the company. For identifying the company, Member States may need to connect an Attribute Provider. For validating powers, the Member States need to connect their Mandate Management Systems. Furthermore, in the second iteration, Member States need to extend their eIDAS implementation with additional (SEMPER) attributes to allow for fine-grained powers validation (and communication). All this requires adapting the eIDAS node, without using the added functionality in the regular eIDAS flows (the non-pilot flows). Pilot partners prefer to use a dedicated pilot node for this.

Powers validation

Regarding powers validation, the DBA pilot implements the following principles:

-         validate powers online;

-         validate powers in the Member State of powers registration;

-         trust the outcome of powers validation abroad;

-         validate powers each time a user authenticates;

-         use the SEMPER-standard for describing the scope of powers to be validated (second iteration).


Concerning powers validation, the piloting partners decided:

-         to use currently operational sources of mandate information instead of building new mandate management solutions to pilot[4];

-         to focus on validating full powers for the first iteration and fine grained powers in the second iteration;

-         not to allow for specific limitations to powers, e.g. joint powers;

-         not to charge fees for validating powers;

-         to use the eIDAS legal person attributes to identify the company represented;

-         to use SEMPER for an explicit powers declaration in the second iteration.


MS Pilot full powers in first pilot iteration Pilot more fine grained powers in second iteration Use SEMPER extension in second iteration
 AT Yes Yes Yes
 NL Yes Yes Yes
 RO Yes, by issuing dedicated pilot credentials to legal representatives (having full power) only. Yes Yes
 SE Yes Yes Probably not

Record matching

Natural person record matching

The company is the entity concerned in the DBA pilot. The main focus of the pilot participants is on recognising the company, although matching the natural person representative is needed in AT for inclusion in the national registry of persons (data evaluator role). In AT, the data evaluator can only fulfil the eProcedure after registering the natural (and the company) in the national registry. None of the data providers require record matching on the natural person.


Company record matching

For recognising the company at the data provider for retrieving the evidence, the pilot partners agreed to use the national business register number as eIDASLegalPersonIdentifier. In the 2 Member State scenario – which the DBA pilot is limited to – this guarantees unique identification of the company by the national business register number received via eIDAS, without the need for any company record matching on any of the additional attributes[5].

Some data consumers (AT and NL) require record matching on the company to find companies (that apply for an eService) registered without an  eIDASLegalPersonIdentifier, prior to the pilot start. Record matching may be done upfront (NL, to add the eIDASLegalPersonIdentifier to already registered foreign companies before the pilot starts) or in runtime at login (AT). Some data consumers implement a dedicated portal for piloting starting with an empty company registry. These Member States will register the eIDASLegalPersonIdentifier from the start, so no additional record matching needs to be implemented. In any case, this matching process is DC-specific. It does not need any additional common components, nor does it require additional eIDAS attributes.

MS DC matching on company[6] DC matching on natural person DP matching on company[7] DP matching on natural person
 AT Yes Yes Yes,

using eIDASLegalPersonIdentifier

No
 NL Yes, probably prior to pilot No Yes,

eIDASLegalPersonIdentifier

No
 RO No, due to use of pilot eProcedure portal and registry No Yes,

eIDASLegalPersonIdentifier

No
 SE No, due to use of pilot eProcedure portal and registry No Yes,

eIDASLegalPersonIdentifier

No


Explicit request, preview & logging

In the DBA pilot the data evaluator will secure the explicit request from the user and present the user with the preview. Contrary to the user supported intermediation pattern, the DBA pilot will not implement a preview at the data provider. There will not be any user interaction with the data provider.


Although several exceptions exist to the need for an explicit request and the option to preview the evidence in the SDGR, the DBA pilot will implement both functions without applying these exceptions (explicit request will always be secured and preview will always be displayed). This way it reduces complexity, improves user centricity and adds project value in allowing maximum user feedback on both functions. In the MVP, the explicit request and preview will be implemented in a simple form to focus efforts on the pilot priorities (use of eIDAS on behalf of a company and the exchange of company data evidence).


As the explicit request & preview will be implemented in a simplified form, there is no need for request tokens as proof of explicit request and extensive logging of user activities in the first pilot iteration. Logging is needed for solving errors as they occur. Furthermore, there is no need for advanced layout of the data to preview in the first pilot iteration. The canonical Company registration evidence will be presented for preview as a simple overview These functionalities may be added in the second iteration (depending on the evaluation of the first iteration). In any case, the second pilot iteration will add functionality to present the domestic evidence as addition to the canonical evidence.

Company registration evidence

The detailed design of the pilot process has confirmed that all pilot partners can work with just one single company registration evidence type that will be provided free of charge by the data owner. There is no need for introduction of additional evidence types for this pilot. The company registration evidence type is characterised by:

  • A small number of mandatory attributes and a large number of optional ones to allow all data providers to construct the evidence.
  • One request will be fulfilled with exactly one response.
  • Data will not be requested from multiple data providers at once (‘multiple evidence cases’).
  • The company registration evidence is fully structured data.
  • In the second iteration, domestic evidence (an image or PDF) may be included within the evidence structure (as attributes), but this will not be piloted in the first iteration.
  • BRIS has been taken into account in the definition of the evidence type for its semantic aspects. The main aspects of this alignment are that conform BRIS the EUID is used as identifier for the company and that the value list for the company status is conform BRIS.
  • Where feasible is aligned with the core vocabularies. Main aspects of the alignment with the core business vocabulary is the use of the element Legal Entity Legal Name including the support for multiple languages. The core business vocabulary object Address could not be used because it doesn’t match the DBA requirements. DBA prefers to have one complete address per language instead of one address with repeating elements (e.g. street names, cities), one for each relevant language.


The main elements of the company registration evidence type are:

  • Legal entity identification
  • Legal entity attributes
  • Contact points
  • Activities
  • Branch (not included in first pilot iteration)
  • Address


The attribute definition of the Company Registration Data evidence is included in section 3.5. In section 3.7 is described in which component the Member States transform their domestic evidence to the company registration evidence and vice versa.

Business Register Interconnection System (BRIS)

The BRIS network will not be used in the DBA pilot. Although there are similarities between BRIS and the SDGR, the differences prevent inclusion of the one in the other. Blocking differences to use BRIS for exchange of Company registration evidence in DBA are for example:

  • use of BRIS is not allowed for public authorities other than business registers (e.g. the AT and NL cases)
  • BRIS is too limited regarding the legal types it supports
  • The BRIS data set does not fully correspond with the data requested by the DBA data evaluators
  • BRIS and SDGR have different requirements regarding user involvement in data exchange, e.g. SDGR requires explicit request and preview, while BRIS does not
  • Both the OOP TS and the BRIS network are governed by their own regulation and may develop independently (alignment is not guaranteed in any sense)

In defining the DBA evidence data model, the DBA pilot used the BRIS data definitions as much as useful.

Retrieved from ‘https://wiki.de4a.eu/index.php?title=DBA_UC1_major_design_decisions&oldid=2121’