Use Case "Starting a Business in Another Member State" (DBA UC1)

Back to Doing Business Abroad main page

[Final]

At the core of this use case is the fulfilment of procedural obligations to do business in another Member State, especially the initial registration of a company at an eProcedure portal (AT, NL and RO pilot scenarios), opening a branch and the assessment of tax duties in the destination Member State (in the Swedish pilot scenario). In this use case, a company representative authenticates to the eProcedure portal, registers the company at the portal and applies for a service.

This UC uses the Intermediation Pattern and the Subscription and Notification Pattern.

Definition

The first use case ends with a subscription to receive notifications of business events of the company involved. From a logical process point of view, this is strongly intertwined with the company registration: subscribing to notifications follows directly after registration of the company at the eProcedure portal, before the process ends. Hence it is an integrated part of the first use case. From an interaction pattern perspective, the subscription to notifications does not belong to the intermediation pattern but to the subscription & notification pattern. The first part of the subscription and notification pattern deals with managing subscriptions, the second part with sending notifications once a business event took place. So, the first use case spans two interaction patterns.

Major design decisions

• Two Member State intermediation scenario
• Real eProcedures and simulated eProcedures
• Real data and fictitious data
• eIDAS network and non-notified eIDs
• Powers validation
• Record matching
• Explicit request, preview & logging
• Company registration evidence
• Business Register Interconnection System (BRIS)

Process

The first version of the pilot process has been analysed and specified in the D4.5 deliverable. Subsequently, the processes have been further detailed by each of the pilot partners for their specific situation, required functionality has been specified, the processes have been aligned to the project start architecture (that has been designed after the delivery of D4.5), the solution architecture has been defined, national customisations and integration activities and gaps have been identified. This section specifies the interpretation of the reference pattern for the DBA pilot (see project start architecture).

Points of attention when comparing to the initial pilot process design from D4.5 and the Member State specific detailed process designs (based on the solution architecture):

• Use case 1 cannot be implemented fully with the intermediation pattern. The subscribing of a company for updates is not part of the intermediation pattern and is not included in the first pilot iteration.
• The process “request authentication” (DE) in the DBA pilot includes also (1) requesting the identifying attributes of the company represented and (2) requesting a powers validation. This does not contradict to the reference pattern, but needs highlighting because of its importance for the DBA pilot.
• The process “provide authentication details” (user) in the DBA pilot includes also identifying the company that the user wants to represent. This may be done by entering the company identifier, by selecting the company from a list of companies the user has powers for or by directly selecting the mandate to use. In any case, the user’s powers to represent need to be validated. The implementation is Member State specific and does not need harmonisation for piloting.
• The process “establish user identity” (user) in the DBA pilot refers to record matching on the company represented as outlined in section 3.3.6.
• The process “redirect user to another channel” (user) in the DBA pilot means: allowing the user to register the company by using currently existing in-person or paper-based procedures.
• The process “determine procedural requirements” and “determine required cross-border evidence” have been simplified for the DBA pilot to reflect the decision to use just one evidence type. The procedural requirements and evidence to request are fixed in the scenario of each pilot partner.
• Saving and resuming the eProcedure (user) is not supported in the DBA pilot.
• “Provide public service” in the DBA pilot initially means: registering the company at the eProcedure portal. Registering the company in all pilots’ scenarios is the pre-requisite for applying for eServices, like assessment of tax duties, filing tax and applying of a subsidy or grant.

Data model

• Data model diagram
• Attribute specification

Components

Common eIDAS components

Component	Role	Short description of its use
eIDAS connector	eIDAS connector	The component Member States implement to connect to the eIDAS network as a relying party. The connector accepts authentication requests from the service providers of the Member State and forwards the requests to the Member States that needs to authenticate the user. After authentication, the eIDAS connector receives the authentication results and sends them to the requesting service provider (relying party). The eIDAS connector can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.
eIDAS proxy	eIDAS proxy	The component Member States implement to allow authentication with their (notified) eID for services provided in other Member States. The eIDAS proxy receives authentication requests from relying Member States, coordinates authentication, retrieval of legal person attributes and powers validation. The eIDAS proxy then sends the result to the requesting eIDAS connector. Just like the eIDAS connector, the eIDAS proxy can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.
SEMPER extension	eIDAS connector and eIDAS proxy	To be used in final pilot iteration only: The eIDAS interoperability architecture as well as the CEF reference implementation allow for extension of eIDAS with additional – domain specific – attributes. The SEMPER project used this option to include attributes on the powers requested (‘powers validation request’) and the result of powers validation (‘the powers declaration’). The SEMPER extension leaves the eIDAS functionality untouched, but extends its use with an addition to the SAML profile and the Light protocol.

Common OOP TS components

Component	Role	Short description of its use
Evidence service locator (ESL) configuration file	Data requestor and data transferor	As the DBA pilot’s MVP uses just one type of evidence, with just one data provider per Member State (on NUTS0 level), there is no need for dynamic discovery of the data provider and its data services. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (Member State and participant id). The ESL configuration file is also called “Information desk configuration file”. The file will be integrated in the DE4A connector. It is replaced by full Information Desk functionality in the second pilot iteration.
SMP	Data requestor and data transferor / central	For each evidence request and response, information on the receivers Access Point (URL) and its certificates are needed. Each Member State hosts an SMP for this purpose. Before sending a request or response, the sending party queries the SMP of the receiver to get this information. For initial testing purposes the SMP will be hosted centrally to ease implementation.
DNS & SML	Data requestor and data transferor	As there are multiple SMPs, the sending party needs to know where to find the SMP of the receiver to get the actual metadata. This location can be found in the centrally CEF-hosted DNS, that will be queried by the access point of the sending Member State. DNS entries will be created from the registration of SMPs: the SML, which is also centrally hosted by CEF.
eDelivery AS4 Gateway	Data requestor and data transferor	This component – also referred to as eDelivery access point – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals.
DE4A Connector	Data requestor and data transferor	The DE4A connector is the reference software that data requestors and data transferors can use to connect to the OOP TS. This eases the work by abstracting the communication with the components. The DE4A connector handles all communication with the ESL configuration file, DNS & SML and AS4 gateway. The DE4A connector will include an AS4 gateway (Phase4). AT, NL and RO will use this integrated gateway.