DBA 2nd iteration Solution Architecture
Back to Doing Business Abroad main page
This is not a formal pilot deliverable, but aims to translate the PSA to a Doing Business Abroad context.
[Final]
1 DBA pilot iteration 2
The 2nd pilot iteration for DBA consists of:
- extending use of the intermediation pattern to allow for more fine grained powers validation: see chapter 2.
- the Subscription and notification pattern: see chapter 3.
- the Lookup pattern (the lookup of evidence, not individual attributes): see chapter 4.
Chapter 5 specifies two additional requirements for the intermediation pattern to initiate subscriptions.
2 Solution architecture for DBA authentication and powers validation
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS is used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.
In all DBA cases a natural person represents a company in the cross-border eProcedure. In both iterations the powers of the representative are validated. The granularity is different in both iterations though. In the first iteration only full powers will be validated. The pilot partners will use currently available eIDAS functionality for communicating this cross-borders. The second pilot iteration adds fine-grained powers validation to eIDAS. It allows for explicit expression of powers in a powers validation request and powers declaration. This requires extension of eIDAS with the SEMPER concepts and software.
2.1 General design decisions
The DBA eIDAS architecture has been designed according to the following general design decisions (see DBA deliverable D4.6):
- The DBA pilot implements a pilot-eIDAS-network, meaning the Member States will implement dedicated pilot eIDAS nodes for cross-border authentication and powers validation that is isolated from the regular network of eIDAS nodes. As the project extends on the use of eIDAS with legal person attributes and powers validation, regular eIDAS nodes are not suitable for piloting. Furthermore, use of the dedicated eIDAS network allows for acceptance of non-notified eID for piloting only.
- The DBA pilot uses the eIDAS company identification attributes ('legal person attributes in eIDAS') to communicate the represented legal person to the DP. As most Member States do not provide these attributes currently, they need to be added for piloting.
- The DBA pilot uses eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.4.
- The DBA pilot uses the SEMPER extension that is compatible with the eIDAS node 2.4 for fine-grained powers validation in the second pilot iteration.
Compared to current eIDAS practice, the use of eIDAS is extended by the DBA pilot with:
- Requesting and sending legal person attributes (identifying the company that applies for the service). Although eIDAS has been able to send legal person attributes from the start, this functionality has been notified just twice (by IT and NL) and has not been used in production services.
- Validating powers of representation. This function is not part of the eIDAS-network currently.
Ad 1. Legal Person attributes & record matching at the DC
- The pilot partners will send the mandatory eIDAS attributes for the legal person after successful authenticating and validating powers (LegalPersonIdentifier and LegalName).
- The Data evaluator in the DBA pilot needs record matching on the company to determine whether the company has been registered at the company portal prior to the pilot start (without LegalPersonIdentifier). The data evaluator will use the second mandatory eIDAS attribute (LegalName) for that purpose. If needed the Data evaluator interacts with the user to do additional checks in the matching process. Record matching at the data evaluator is an eProcedure portal (or data consumer) specific activity that does not need harmonisation across piloting partners.
- The data owner does not need to do record matching on the company as it can use the LegalPersonIdentifier to uniquely identify the company involved. This is a consequence of the pilot principle, that the authenticating proxy sends a LegalPersonIdentifier containing a company identifier that the business register itself uses in its company registration.
- Data evaluators and data owners do not need to do record matching on the natural person. Therefore, no additional eIDAS attributes of the natural person are needed.
For more information, please see DE4A D4.6 DBA Pilot Planning v1.0 final.pdf
Ad 2. Powers validation
- Pilot iteration 1 supports implicit full powers only. It uses the eIDAS network currently operational for sending the required information. The eIDAS infrastructure – from the start – supported exchange of natural person attributes as well as company identification attributes (‘legal person attributes’). The eIDAS regulation defined the minimum datasets for both the natural and the legal person. The eIDAS network lacks a possibility to specify the powers of representation though; attributes specifying the powers (‘the powers declaration’) have not been defined yet. Hence, in iteration 1 the pilot partners agreed on the following access policy rule: “In case of full powers, the eIDAS authentication will be successful and the authentication proxy sends the eIDAS legal person attributes as well. In case of insufficient powers, the authentication must fail at the eIDAS proxy.”. Only that way the data consumer knows whether the user has full powers or not.
- Pilot iteration 2 supports fine grained powers validation. By using the SEMPER extension on eIDAS, not only the natural and company identification attributes can be exchanged, an explicit powers declaration will be included as well. Using the extension, the data evaluator specifies the scope of the service the user needs powers for. After validating the powers, the authentication proxy constructs a powers declaration confirming or denying the person’s powers. This way, the extension allows for fine-grained powers validation.
Main design decisions regarding fine grained powers validation in iteration 2:
- the DBA pilot allows for representation of legal persons by natural persons only.
- the DBA pilot does not allow for intermediary parties (e.g. employee of an accounting firm operating on behalf of the company).
- the DBA pilot operates a list of harmonised services to express the extent of powers. Non-harmonised services will not be supported.
- the DBA pilot uses the SDG annex II procedures as starting point for the list of harmonised services.
- the DBA pilot implements fine grained powers using the SEMPER extension to eIDAS or implement the SEMPER concepts in custom eIDAS software.
For more information, please refer to DE4A D4.6 DBA Pilot Planning v1.0 final.pdf
2.2 Process realisation
The table below presents the components that implement the application services for the DBA pilot.
| Process | Application service | Components |
| Request authentication, including powers validation | Authentication initiation | eProcedure portal front-end
eProcedure portal back-end |
| Specific eIDAS connector | ||
| eIDAS connector | ||
| SEMPER extension | ||
| Authenticate user | User authentication | Identity Provider |
| Validate powers of representation | User authentication | Mandate Management System |
| Retrieve legal person attributes | User authentication | Legal Person attribute provider (may be same as Mandate Management System) |
| Provide authentication details, including powers declaration | User authentication | Specific eIDAS proxy |
| eIDAS proxy | ||
| SEMPER extension |
2.3 Component description
The table below describes each of the components in this solution architecture.
| Component | Type | Short description of its use | Changes for 2nd iteration piloting |
| eProcedure portal Front-end | DC specific | The eProcedure portal Front-end handles all user interaction on the web. For piloting DBA, the eProcedure portal Front-end needs to add the eIDAS login option to the login-webpage. As the DBA Pilot uses a dedicated network of eIDAS nodes, the eIDAS login option should be separated from the regular eIDAS login option (in case not already available on the eProcedure portal). | None. |
| eProcedure portal Back-end | The eProcedure portal Back-end connects to the national eIDAS node via the specific eIDAS connector. The DBA login option should invoke the dedicated eIDAS connector instead of the regular one (a different URL).
Furthermore, the eProcedure portal Back-end should evaluate the authentication result received from the eIDAS connector. |
In iteration 1 the eProcedure portal should request:
In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:
In iteration 2 the eProcedure portal should request:
In iteration 2 the eProcedure portal should apply the following rules for granting access after authentication:
| |
| Specific eIDAS connector | Member State Specific | The Member State specific component that translates national eID protocol into eIDAS (light) protocol for requesting authentication and powers validation.
Member States usually implement one or more components to ‘bridge’ eIDAS to the national eID infrastructure. As from CEF eIDAS reference software 2.0, Member States use the eIDAS Light protocol for this. |
To enable fine grained powers validation in iteration 2, the specific eIDAS connector needs to be extended for requesting powers validation alongside authentication. |
| (pilot) eIDAS connector | Common component (MS deployment) | The component Member States implement to connect to the eIDAS network as a relying party. The connector accepts authentication requests from the data evaluators 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 data evaluator.
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. |
No changes in 2nd pilot iteration. |
| SEMPER extension | Common component (MS deployment) | Component for extending the eIDAS connector and the eIDAS proxy to allow for explicit powers validation requests and powers declarations. | Needs to be deployed by Member States for communicating fine grained powers in iteration 2.
This component has been developed by the SEMPER project and needs to be deployed on the eIDAS node of each of the Member States. As an alternative Member States May develop a custom implementation of the SEMPER software that complies with the SEMPER SAML interface specifications. |
| (pilot) eIDAS proxy | Common component (MS deployment) | 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. |
No changes in 2nd pilot iteration. |
| Specific eIDAS proxy | Member State Specific | The Member State specific component that translates national eID protocol into eIDAS (light) protocol for performing authentication and powers validation. Member States usually implement one or more components to ‘bridge’ eIDAS to the national eID infrastructure. As from CEF eIDAS reference software 2.0, Member States use the eIDAS Light protocol for this. Furthermore, the eIDAS proxy coordinates the login process at the DP Member State by triggering the IdP, Legal Person AP and MMS. | In the second pilot iteration the Specific eIDAS proxy needs to be adapted to translate the powers validation request (the scope of powers to be precise) to national powers taxonomy, send a powers validation request to the Mandate Management System in national protocol, receive and interpret the response from the Mandate Management System and translate it back to cross-border taxonomy. |
| Identity Provider | Member State Specific | The Identity Provider handles authentication of the natural person. The IdP may be notified under eIDAS, but does not need to be notified to be used in the DBA pilot. | No changes in 2nd pilot iteration. |
| Legal Person AP | Member State Specific | Member States need to provide the identifying (mandatory) attributes of the legal person (eIDASLegalPersonID and eIDASLegalName) to the specific eIDAS proxy. Member States could provide optional attributes of the legal person. The Legal Person attributes may be integrated in the national eID scheme. For example, in eRecognition (NL) the mandate management system also provides the legal person attributes. Mandate Management System and Legal Person AP are one and the same component then. | No changes in 2nd pilot iteration. |
| Mandate Management System | Member State Specific | Member State specific solutions for registration and validation of powers. | In the DBA first pilot iteration, this source must be used to verify full powers. The declaration of powers that results from validating full powers is implicit: in case the authentication is successful, the user will have full powers to represent the company.
In the second pilot iteration, when using SEMPER, the powers declaration is explicit: the powers declaration relates to the requested powers declaration and can be a powers declaration for a specific eService as well as a (explicit) powers declaration for full powers. Optionally (depending on national implementation) the harmonised services need to be included in the MMS. |
2.4 Functional requirements
The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
| Role | Component | Requirement |
Use in pilot iteration 1 |
Use in pilot iteration 2 |
| Data evaluator | eProcedure portal | The eProcedure portal adds an eIDAS login option for piloting. | x | x |
| The eProcedure portal connects to a dedicated eIDAS pilot node. | x | x | ||
| The eProcedure portal requests eIDAS legal person attributes (mandatory ones) | x | x | ||
| The eProcedure portal grants the user access on behalf of the company in case of an “authentication successful” response. | x | |||
| The eProcedure portal additionally constructs a fine-grained powers validation request. | x | |||
| The eProcedure portal validates the Powers declaration received. | x | |||
| Authentication connector | SEMPER extension | MS implements SEMPER extension to the eIDAS connector. | x | |
| Specific eIDAS connector | MS adapts the "specific eIDAS connector" to support powers validation requests and powers declarations | x | ||
| eIDAS connector | MS implements eIDAS connector 2.4. In case of a custom implementation (like Sweden) an attribute profile 1.1-compliant version of the connector will be used for piloting. | x | x | |
| Authentication proxy | SEMPER extension | MS implements SEMPER extension to the eIDAS proxy. | x | |
| Specific eIDAS proxy | MS adapts the "specific eIDAS proxy" to support powers validation requests and powers declarations | x | ||
| eIDAS proxy | MS implements CEF eIDAS proxy 2.4.
In case of a custom implementation (like Sweden) an attribute profile 1.1-compliant version of the connector will be used for piloting. |
x | x | |
| MS connects an IdP to the eIDAS proxy node for authenticating the natural person | x | x | ||
| MS connects attribute provider (AP) to eIDAS node for eIDAS legal person attributes (in case not integrated in the MMS) | x | x | ||
| MS connects mandate management system (MMS) to eIDAS node for validating powers. Note: AP and MMS could be the same data source. | x | x | ||
| MS validates (implicit) full powers | x | |||
| MS adds fine-grained powers validation | x |
2.5 Component Deployment
The table below shows the required deployment of common components.
| Component | Version |
|---|---|
| eIDAS connector | CEF reference software version 2.4
or custom software implementing interoperability specs 1.1 |
| eIDAS proxy | CEF reference software version 2.4
or custom software implementing interoperability specs 1.1 |
| SEMPER extension | The 2.4-compliant version of the SEMPER extension provided by Technical University Graz (SEMPER project) |
Open questions AT:
- can we upgrade to eIDAS node 2.5? No compatible SEMPER extension available (check with TUG).
- can we adapt the way we request attributes for iteration 1? -> don't request the natural person attributes, use the natural person representative attributes for this (profile 1.2 style).
2.6 Configuration of authentication requests
Configuration for pilot iteration 1
- regular eIDAS request & response
- eIDAS attributes to request: natural person and legal person attributes (at least the mandatory ones)
- eIDAS attributes to respond with: natural person and legal person attributes (at least the mandatory ones) - including a copy of natural person attributes as representative is optional.
Configuration for pilot iteration 2
- regular eIDAS request & response
- eIDAS attributes to request: legal person attributes only (at least the mandatory ones)
- eIDAS attributes to respond with:legal person attributes (at least the mandatory ones) and representative natural person attributes (at least he mandatory ones) using the representative-prefix
- powers validation request & powers declaration (response)
- request:
- scope of powers to validate
- type of representation allowed
- source of powers accepted
- response:
- validation result (successful or not)
- type of representation
- source of powers
- request:
2.7 Configuration of harmonised services
Principles for configuration:
- The DBA pilot relies on a common library of services to express the extent of powers: the harmonised services. This way, each of the participating Member States understand the powers validation requests of other Member States. It's up to each of the Member States to translate the harmonised services into nationally defined services (authentication connector-side) / powers (authentication proxy-side).
- The DBA pilot uses the SDGR services as starting point. These services have been defined in European legislation (as procedures in annex II of the Regulation). Hence, they have been pre-defined and harmonised already across Europe. The DBA pilot defines the "SDGR" harmonised services catalogue for use in the SEMPER extension.
- The DBA pilot is not limited to SDGR services though, e.g. opening a branch cross-border is explicitly excluded from the SDGR, but is included in some of the pilot scenario's. For services 'beyond SDGR' the DBA pilot has defined the "SDGRplus" harmonised services catalogue.
Proposal for the harmonised services to express powers cross-border:
| Service catalogue | Nr | Harmonised service |
|---|---|---|
| SDGR | 1 | Notification of business activity, permission for exercising a business activity, changes of business activity and the termination of a business activity not involving insolvency or liquidation procedures |
| SDGR | 2 | Registration of an employer (a natural person) with compulsory pension and insurance schemes |
| SDGR | 3 | Registration of employees with compulsory pension and insurance schemes |
| SDGR | 4 | Submitting a corporate tax declaration |
| SDGR | 5 | Notification to the social security schemes of the end of contract with an employee, excluding procedures for the collective termination of employee contracts |
| SDGR | 6 | Payment of social contributions for employees |
| SDGRplus | 1 | Starting of a company or opening a branch in another member state |
| SDGRplus | 2 | Initial registration of a business activity with the business register |
2.8 Logical interfaces
SAML interface specifications for regular authentication requests (pilot iteration 1) have been specified by CEF Digital: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+eID+Profile
SAML interfaces specification for SEMPER-extended authentication request and response (pilot iteration 2) have been specified by SEMPER: see chapter 6 from deliverable M3 Report on mandate attributes and solutions for cross-border mandate attributes - 1.0.
3 Solution architecture for Subscription & Notification pattern
This section specifies the solution for the Subscription & Notification pattern that will be piloted by the DBA pilot in the second iteration.
Within scope of the DBA pilot:
- Modify DO/DE Mocks for the S&N pattern: for testing the S&N pattern, new versions of the DO- and DE-mocks need to be developed by the technical workpackage within DE4A.
- Common component for Cross-border subscriptions and notification.
- Event Notification, in line with PSA 2nd iteration: the PSA defines several options for implementing the S&N pattern. The option chosen provides a solution for notifying business events and triggering of the Lookup pattern in case (an updated version of) evidence is required by the DE.
Outside scope of the DBA pilot:
- Inspecting the log files for examining an error in sending a subscription request or notification.
- Resend a subscription request in case of an error;
- Resending a notification in case of an error (notification front-end);
- Include the Evidence in the notification: in case the DE needs (an updated version of) the evidence, it will use the Lookup pattern.
- Authorisation of DE's subscribing and DO's notifying (the component "authorization controller").
To be analysed by semantic experts within DE4A:
- DBA requests the semantic experts to examine the authorization controller for the S&N pattern. The DBA partners don't require the authorization controller for piloting, but are aware this component is needed in case of large scale use of the S&N pattern. For the S&N pattern, the authorization controller should:
- Establish whether the DE is allowed to subscribe. This prevents unauthorised access to company data (in the form of notifications). This authorisation should be checked by the DT.
- Establish whether the DO is allowed to send a notification. This prevents unauthorised sending of (fake) notifications. This authorisation should be checked by the DR.
Prerequisite from the DE4A-project is the use of eDelivery and AS4 for the exchange of messages in the S&N and Lookup patterns. This means that eDelivery will be used for:
- requesting a subscription (DE to DO)
- confirming a subscription (DO to DE)
- notifying a business event (DO to DE)
In the next sections the general design decisions, process realisations, component descriptions, requirements, component implementations and expected logical interfaces are described.
3.1 General Design Decisions
The following design decisions have been applied to the solution for S&N:
- The DBA pilot uses one type of subscription message and one type of notification message that all DC’s and DP’s involved will use. The subscription message is for subscribing to cross-border events generated at the DP. The notification message is for notifying the DC of such events. If the DC desires the Evidence can be retrieved using the Lookup. This implies an update of the IEM (to be provided by the semantics work package in DE4A).
- There will be just one data owner per Member State: the business register, where the subscription will be recorded and where the cross-border events are generated, i.e. the authentic source of company information. The pilot does not support multiple DO's / notifying authorities in one Member State.
- For a given subscription provider (data owner), just one subscription is allowed per combination of (a) data evaluator, (b) company and (c) event catalogue. In other words, the DE can not register multiple subscriptions for one single company and one event catalogue at a subscription provider. If this is required in the future (after piloting DBA), then this functionality needs to be added to the solution.
- Using a single subscription request, the DE will subscribe to updates for a single company in a single Member State.
- As soon as the DE wants to subscribe to updates of multiple companies at one DO, it needs to send multiple subscription request to that DO (one for each company it wants to subscribe to).
- As soon as the DE wants to subscribe to updates for one company in two Member States, it needs to request two separate subscriptions, one for each Member State. This use case is not applicable to the DBA pilot though.
- A notification concerns only one single event of one single company and will be addressed to only one Member State.
- In case DE's from different Member States have subscribed to business events of a specific company, the DP needs to notify each of the Member States individually.
- In case the DP needs to notify a DE of multiple events for a specific company, the DP needs to send multiple notifications (one for each event).
- In case the DP needs to notify a DE of one event impacting multiple companies, the DP needs to send multiple notifications (one for each company).
- Business event notification is considered an extension to the SDGR, hence explicit request and the preview functions won't be implemented.
- The S&N pattern has been designed without any user interaction.
- In contrary to the PSA for this pattern, the ending date & time for a subscription are voluntary, meaning that as long as the DE has not indicated the ending date & time, the subscription remains valid. Mandatory ending dates & time may lead to arbitrary ending dates set in the far future by the DE. Furthermore, there seems to be no legal basis for maximising the subscription period to - for example - 5 years.
- In this solution the DE is in charge of its subscriptions at any time. There is no requirement to allow the data owner to end subscriptions single handed (e.g. after the company ended its operation).
The OOP TS domain (to b provided by the technical work package of DE4A) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.
3.2 Process realisation
The solution for the S&N patterns includes required functionality of the OOP Technical System (common components) expressed as application components and interfaces in the diagram below. Some common components need to be implemented by the data requestor and data transferor, some components by the data evaluator and data owner and some are common components to be implemented by the DE4A technical workpackage. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.
The table below presents the components that implement the application services for the DBA pilot. The process realisation is split in two (subscription and notification) as they are independently triggered. See Subscription and Notification in the Project Start Architecture (PSA 2nd iteration) for more details.
3.2.1 Subscription
| Process | Application Service | Components |
| Initiate subscription (DC) | Subscription Initiation |
|
| Change subscription (DC) | Subscription Initiation |
|
| Lookup event provider routing information (DC) | Inquire Routing Information | |
| Send subscription request (DC) |
|
eDelivery access point: |
| Validate subscription request (DP) |
|
eDelivery access point:
|
| Evaluate subscription request (DP) | Subscription Evaluation | Subscription System |
| Exception: Prepare subscription error message (DP) | Subscription Error Handling |
|
| Exception: Send subscription error message (DP) |
|
eDelivery access point:
|
| Exception: Forward subscription error (DC) |
| |
| Exception: Investigate reason for subscription error (DC) | out of scope | out of scope |
| Register subscription (DP) | Subscription Creation and Update | Subscription System |
| Confirm subscription (DP) | Subscription Confirmation |
|
| Send subscription confirmation (DP) |
|
eDelivery access point:
|
| Forward confirmation (DC) | n/a |
|
| Log subscription information (DC) | n/a | eProcedure Back-office Backend |
3.2.2 Notification
| Process | Application Service | Components |
| Identify cross-border event (DP) | Cross-border Event Filter | Cross-border Event Handler |
| Check subscriptions (DP) | Subscription Lookup |
|
| Prepare notification message and subscriber list (DP) | Notification Message and Subscriber List Preparation |
|
| Exception: Resend past events (DP) | out of scope | out of scope |
| Resolve service metadata (DP) | Inquire Routing Information |
|
| Exception: Resolve subscriber participant ID and inform National Contact Point (DP) | out of scope | out of scope |
| Send event notification (DP) |
|
eDelivery Access point:
|
| Validate event notification (DC) |
|
eDelivery Access point:
|
| Determine event response (DC) | Event Evaluation | eProcedure Back-office Backend |
| Request change of subscription (DC) |
|
eProcedure Back-office Backend |
| Dismiss event (DC) | Update Notification Response Log | eProcedure Back-office Backend |
| Trigger evidence lookup (DC) | Update Notification Response Log | eProcedure Back-office Backend |
| Notify Responsible Organization (DC) | Update Notification Response Log | eProcedure Back-office Backend |
3.3 Component description
The following table lists the components indicated in the image above. Per component a short description of its use is given, by which role the component is used (i.e. DE, DR, DT, DO) and whether the component is MS specific or common functionality.
| Component | Short description of its use | Role | Genericness* | Changes for 2nd iteration piloting |
| eProcedure Back-office Backend | This component implements back-end functionality for executing the eProcedure. Examples in the context of S&N:
|
DE | specific | Requires new functionality for S&N pattern in each of the DE's.
|
| Back-office to OOP TS | Interface for connecting the DE's backoffice with the OOP TS for:
Just like the portal to OOP TS interface (as described in the DBA first iteration solution architecture), Member States may choose to implement this interface in a generic way to bridge national OOP protocols to DE4A datamodel at one single place. Furthermore, Member States may choose to integrate both interfaces (portal to OOP TS and backoffice to OOP TS) in one single interface. |
DR | specific | Needs to be developed and implemented for the second iteration.
May be partial re-use of the portal to OOP TS interface. |
| DE4A Connector | Taking care of eDelivery and IDK interfacing, shielding DR and DT from complexities and facilitating ease of implementation.
Error handling and logging. |
DR, DT | common | Needs extension for S&N pattern to facilitate interaction on:
- subscriptions - notifications |
| IDK | DE4A playground IDK: a web application for locating the service to reach out to. | DR, DT | common | Change w.r.t. iteration 1? There is no evidence provider lookup, instead the endpoint where to send the subscription request to is needed. Also there is no evidence response.
See logical interfaces section below |
| MS SMP | For each subscription request/response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose (note: for testing one single centrally hosted DE4A SMP will be used). Before sending a request or response, the sending party queries the SMP of the receiver to get this info. | DR, DT | common | None expected. |
| eDelivery Access Point | This component – also referred to as eDelivery AS4 gateway – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals. | DR, DT | common | Needs configuration for accepting subscription, notifications and lookup messages for the second iteration. |
| DNS & SML | As there are multiple SMP’s, 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 SMP’s: the SML, which is also centrally hosted by CEF. |
Central | central | None expected. |
| Cross-border Event Handler | Application component handling the cross-border events. It filters all domestic events for relevant cross-border events and takes care of preparing a notification message and compiling a subscribers list to which the notification must be sent. | DO | common | The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality. |
| Subscription System | Application component managing the entire life cycle of subscriptions, i.e. creation and maintaining subscriptions. It also offers functionality for validating subscriptions (does subject exist?, is the event supported?, is the subscription changing an existing subscription?), confirmation of a subscription and error handling. | DO | common | To be developed
|
*genericness: specific: to be developed, deployed and hosted by MS; common: to be developed by WP5 and deployed and hosted by MS; central: to be developed, deployed and hosted by CEF
3.4 Functional requirements
The table below presents the requirements that the components involved need to implement.
| Component | Nr | DBA requirement | Comment |
| eProcedure Backoffice Backend | 1 | The DE should be able to subscribe to the combination of:
|
For piloting it is sufficient to skip the specification of events to subscribe to. It will be all or none. |
| 2 | The DE should monitor actual subscription at the DO by processing the subscription confirmation / error. | ||
| 3 | The DE should have the option to set a defined time frame for receiving notifications to automatically end a subscription. | ||
| 4 | The DE should be able to manage the “end date” of the subscription (prolong, shorten, …). | ||
| 5 | The DE should be able to unsubscribe to all notifications for a company at once. | See req 1. for piloting a "all or none" subscription is fine. | |
| 6 | The DE should at any time have an overview of all its subscriptions in order to manage them. | ||
| 7 | The DE may process a notification instantly, but may also choose to process the notifications in batch, e.g. once a day or week. | ||
| 8 | The DE should have a legal basis for processing business events. | It’s up to the DE to manage this. The DE will be accountable for its data processing. | |
| 9 | The DE should implement logic to decide when (by which events) to lookup evidence. | ||
| DE4A connector | 1 | The DR must confirm having received the notification (by the DR not the DE) to the DT. | From that point on delivery of the notifications to the DE is the responsibility of the DR (and not the DT or DO). |
| 2 | The DT needs to confirm having received the subscription request to the DR. | ||
| 3 | Each message sent requires a confirmation from the receiving actor (acknowledgement). For technical error messages concerning a subscription, notification or lookup the existing WP5 list can be used. e.g. timed-out, component unavailable, XML error, etc. | Errors need to be implemented for the messages required for both new patterns. | |
| Back-office to OOP TS interface | 1 | The DR should provide a facility for delayed forwarding of notifications to the DE. | The DR probably needs a queue for this. This queue should guarantee delivery of the notifications to the DE, even if the DE is not online at some point in time or some other error prevents sending the notification.
This functionality preferably is not part of the Connector which should remain stateless. |
| Subscription system | 1 | The DO should send a confirmation of registering or changing the subscription to the DE. | Including error code and handling. |
| 2 | The DO should generate one of the following error messages in case of registration error:
1. subscription registration failed (e.g. actor not authorised to subscribe, company identifier not found) 2. subscription change failed (e.g. subscription to change not found in subscription system). |
For piloting these two business errors are sufficient.
Business list of errors might be extended in future releases (after piloting).
| |
| 3 | The subscription system should register:
- data evaluator - company ID - business event - starting date & time - ending date & time |
Please note that, in piloting DBA, pilot partners will implement an 'all or nothing'-subscription. This way, a subscription for a specific company is for all business events at once or for none (no subscription then). Hence, the element "business event" will not be used to differentiate between business events that are and that aren't included in a subscription.
The element "business event" may be included in the components data store for future use though (to be decided by WP5). Furthermore, the element may be generalised to "event" to cover future use of other types of events. | |
| 4 | The subscription system should allow for querying which data evaluators to notify in case of a business event. | ||
| Cross-border Event Handler | 1 | The cross-border event handler should:
|
|
| 2 | The DO should send notifications only for a business event occurring to a company for which the DE has subscribed – for as long as the subscription is valid. | For piloting is seems sufficient to notify one single Member State in case of an event at a time. | |
| 3 | The DO should include the company identifier in the notification to allow the DE to find the corresponding record in its registry. | ||
| 4 | The DO should include additional company identifiers that the business event concern. | E.g. The identifiers of the company / companies acquiring the company concerned. | |
| 5 | The DO should clearly state in the notification what business event has occurred. | ||
| 6 | The DO should provide a timestamp of the business event separate from the timestamp of the notification. | ||
| 7 | The DO may send notifications instantly, but may also send in batch, e.g. once a day or week. | The DE does not confirm receiving the notification to the DO, the acknowledgement of the DE4A connector is sufficient. | |
| 8 | The DO should be able to send notifications independently of the availability of the DE. | In order not to hinder the notification process of the DO. | |
| 9 | The DO should not include any additional company data in the notification nor attach evidence of any type to the notification. | Data minimisation.
It will be up to the DE to process the notification. This might not need any additional data. | |
| 10 | The DO should implement one event for notifying "the company registration evidence has changed" (without specifying which business event has occurred - if any). | To cover for data changes that might be relevant for the DE without being a direct consequence of the occurrence of a harmonised business event, e.g. e-mail address changed. | |
| Data service | 1 | The data service of the DO needs to be capable of detecting business events and triggering a notification. | |
| 2 | The data service of the DO needs to support the event type "Company registration evidence has changed" |
The table below presents the requirements for the DE and DO mocks.
- The DE mock should mock the eProcedure Back-office Backend.
- The DO mock should mock the cross-border event handler and subscription system.
| Component | Nr | DBA requirement | Comment |
| DE mock | 1 | Requesting a subscription:
|
|
| 2 | Show subscription confirmation on web page. | ||
| 3 | Show subscription error on web page. | ||
| 4 | Changing a registered subscription:
|
||
| DO mock | 1 | Subscription system - process requests:
|
|
| 2 | Event handler - Construct and send a notification:
|
3.5 Component deployment
- DNS, SML will be reused from iteration 1.
- SMP, eDelivery Access Point will be reused from iteration 1.
- The IDK probably needs to change to allow for locating the subscription register.
- The DE4A Connector needs an update to support the S&N flows and messages.
- Various MS specific interfaces may be needed for (sub)system integration.
- Both DE and DO need to do bookkeeping of subscriptions.
- The DO needs cross-border event handling functionality
- The DE needs event interpretation functionality and triggers for follow-up actions, like Lookup of evidence.
Expectations for the semantics workpackage of DE4A:
- design messages for subscription request, subscription confirmation, subscription error and notification.
- analysis and design authorisation controller (out of scope for piloting)
Expectation for the technical workpackage of DE4A:
- extend the DE4A connector for S&N
- extend (the configuration of) the integrated AS4 gateway for S&N
- adapt the IDK if required for S&N.
- design and develop the cross-border event handler
- advise on queuing solution for Back-office to OOP TS interface
- examine possibility for generic components for "subscription system" and S&N back-end functionality of "eProcedure back-office backend"
- develop the DE and Do mocks
3.6 Configuration of business events
Business events are defined by each of the Member States individually. Although there are commonalities, all event-lists of the Member States are different. To enable cross-border interpretation of business events harmonisation of events is needed. For piloting DBA, just a small selection of events will be piloted. The purpose of the DBA pilot is not to harmonise all events, but to validate the notification-mechanism.
The DBA event list (catalogue "Business events") builds upon the BRIS definitions.
List of harmonised events in the Event catalogue "Business events":
- Company ended its operations
- Company changed its legal form
- Company merger or takeover
- Company moved to another location
- Company administration changed
- Company registration evidence has changed
TO DO: validate within DBA pilot.
National-to-harmonised translation needs to be designed by each Member State. Example for NL below (concept).
| nr | harmonised event | NL event equivalent |
|---|---|---|
| 1 | Company ended its operations | beëindigen rechtspersoon
opheffen onderneming |
| 2 | Company changed its legal form | omzetten rechtspersoon |
| 3 | Company merger or takeover | fuseren rechtspersoon |
| 4 | Company moved to another location | verhuizen vestiging |
| 5 | Company administration changed | toetreden bestuurder
toetreden functionaris toetreden gemachtigde toetreden aansprakelijke bij samenwerkingsverband uittreden functionaris/bestuurder/gemachtigde/aansprakelijke bij samenwerkingsverband |
| 6 | Company registration evidence has changed | (not an event) |
3.7 Logical interfaces
The expected logical interfaces of the common components are expected to remain largely the same with an expansion for the S&N pattern.
Note: We need to discuss with the semantic / technical experts of DE4A the implementation of the Data Service Lookup ABB. Right now this is covered by the IDK. However, for S&N there is no evidence lookup or exchange, so at least the name is off. Also the I/F with the Connector changes slightly. In the table below some differences are indicated.
| Component | Expected interface |
| IDK | IN (from DE4A connector to IDK):
|
| SMP | IN (from DE4A connector to SMP):
OUT (from SMP to DE4A connector):
|
| DNS & SML | IN (from DE4A connector to DNS):
OUT (from DNS to DE4A connector):
|
| eDelivery AS4 gateway | IN (from DE4A connector to eDelivery Acess Point):
|
| DE4A Connector | Subscription
Initiating or changing subscription IN (from DE to DE4A connector):
OUT (from DE4A connector to DE):
Subscription confirmation IN (from DO to DE):
OUT (from DE to DO):
Notification IN (from DO to DE4A connector):
OUT (from DE4A connector to DR):
|
| Subscription system | IN (from DE4A connector to subscription system) - for subscribing:
OUT:
OUT:
|
| Cross-border Event Handler | IN
|
4 Solution architecture for Lookup pattern
This section specifies the solution for the Lookup pattern that will be piloted by the DBA pilot in the second iteration. Basically, the Lookup pattern will be implemented as the intermediation pattern, but without: user authentication, explicit request and preview. Instead of having the eProcedure portal managing the OOP TS flow in interaction with he user, it will be the eProcedure back-office that will initiate the lookup and process the evidence.
The Lookup pattern will be used to quickly retrieve (updated) evidence needed to keep a local company data store up-to-date, to re-asses a service provided or for generic fraud prevention purposes.
Within scope of the DBA pilot:
- Evidence Lookup, the PSA defines several options for implementing the Lookup pattern. The option chosen is based on requesting (an updated version of) evidence.
Outside scope of the DBA pilot:
- Attribute Lookup: this solution architecture supports Evidence type lookup requesting the full evidence without user interaction. The option to request individual attributes / API-approach is not supported.
- Authorisation of DE's to retrieve the requested evidence (the component "authorisation controller")
To be analysed by the semantic experts in DE4A:
- DBA requests the semantic experts to examine the authorization controller for the Lookup pattern. The DBA partners don't require the authorization controller for piloting, but are aware this component is needed in case of large scale use of the Lookup (and intermediation) pattern. For the Lookup pattern, the authorization controller should establish whether the DE is allowed to retrieve the requested evidence type. This prevents unauthorised access to company data. This authorisation should be checked by the DT.
Prerequisite from the DE4A-project is the use of eDelivery and AS4 for the exchange of messages in the Lookup pattern. This means that eDelivery in the Lookup pattern will be used for:
- requesting evidence (DE to DO)
- sending the evidence (DO to DE)
In the next sections the general design decisions, process realisations, component descriptions, requirements, component implementations and expected logical interfaces are described.
4.1 General Design Decisions
The following design decisions have been applied to the solution for Lookup:
- Based on a received notification message (S&N pattern) the DC, if desired, retrieves the Evidence using the Lookup.
- The explicit request and the preview functions won't be implemented as Lookup is considered 'beyond SDGR'
- The Lookup has been designed without any user interaction.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for performing the lookup of an evidence.
4.2 Process realisation
The solution for the Lookup pattern specifies required functionality of the OOP Technical System expressed as application components and interfaces in the diagram below. Some OOP TS components need to be implemented by the data requestor and data transferor, some components by the data evaluator and data owner and some are common components to be implemented by DE4A WP5. The image below depicts the solution for the Lookup Pattern (LKP) with the familiar split in the different roles.
The table below presents the components that implement the application services for the DBA pilot.
Please note that we assume the common components for the Lookup pattern can be re-used 1-on-1 of the intermediation pattern (same components, same functionality, same deployments). Only the initiation of the evidence request and the processing of the evidence response is different (not eProcedure portal but eProcedure backoffice). Hence, for the common components, just a referral has been included. For more information we refer to the solution architecture of the intermediation pattern.
See Lookup Pattern for more details.
| Process | Application Service | Component |
| Determine required cross-border evidence (DC) | Cross-border Evidence Matching | eProcedure Backoffice Back-end:
Back-office to OOP TS interface |
| Lookup routing information (DC) | See intermediation pattern | See intermediation pattern |
| Request evidence (DC) | See intermediation pattern | See intermediation pattern |
| Evaluate evidence request (DP) | See intermediation pattern | See intermediation pattern |
| Establish subject identity (DP) | See intermediation pattern | See intermediation pattern |
| Communicate non-availability of OOP (DP) | See intermediation pattern | See intermediation pattern |
| Extract evidence (DP) | See intermediation pattern | See intermediation pattern |
| Communicate non-availability or Delay of evidence (DP) | See intermediation pattern | See intermediation pattern |
| Establish non-availability of OOP (DC) | See intermediation pattern | See intermediation pattern |
| Compose evidence response (DP) | See intermediation pattern | See intermediation pattern |
| Transfer evidence (DP) | See intermediation pattern | See intermediation pattern |
| Forward evidence (DC) | See intermediation pattern | See intermediation pattern |
| Evaluate evidence (DC) | Assess Evidence | eProcedure Backoffice Back-end |
4.3 Component description
The following table lists the components indicated in the image above. Per component a short description of its use is given, by which role the component is used (i.e. DE, DR, DT, DO) and whether the component is MS specific or common functionality.
| Component | Short description of its use | Role | Genericness* | Changes for 2nd iteration piloting |
| eProcedure Back-office Backend | This component handles all backoffice functionality for the eProcedure. For the Lookup pattern it:
|
DE | specific | This new functionality needs to be designed and developed by each of the participating DE's. |
| Back-office to OOP TS | Interface for connecting the DE's backoffice with the OOP TS for:
Just like the portal to OOP TS interface (as described in the DBA first iteration solution architecture), Member States may choose to implement this interface in a generic way to bridge national OOP protocols to DE4A datamodel at one single place. Furthermore, Member States may choose to integrate both interfaces (portal to OOP TS and backoffice to OOP TS) in one single interface. |
DR | specific | Needs to be developed and implemented for the second iteration.
May be partial re-use of the portal to OOP TS interface. |
| DE4A Connector | Taking care of eDelivery and IDK interfacing, shielding DR and DT from complexities and facilitating ease of implementation.
Error handling and logging. |
DR, DT | common | No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change. |
| IDK | DE4A playground IDK: a web application for locating the service to reach out to. | DR, DT | common | No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change. |
| SMP | For each subscription request/response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose (note: for testing one single centrally hosted DE4A SMP will be used). Before sending a request or response, the sending party queries the SMP of the receiver to get this info. | DR, DT | common | None expected. |
| eDelivery access Point | This component – also referred to as eDelivery AS4 gateway – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals. | DR, DT | common | No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change. |
| DNS & SML | As there are multiple SMP’s, 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 SMP’s: the SML, which is also centrally hosted by CEF. |
Central | central | None expected. |
| Data Service | The webservice of the data provider that will output the evidence requested. | DO | specific | None expected. |
| Data source to OOP TS Interface | Interface for connecting the data service with the OOP TS (IM & LKP). | DO, DT | specific | None expected. |
*genericness: specific: to be developed, deployed and hosted by MS; common: to be developed by WP5 and deployed and hosted by MS; central: to be developed, deployed and hosted by CEF
4.4 Functional requirements
The table below presents the requirements that the components involved need to implement.
| Component | Nr | DBA requirement | Comment |
| eProcedure Back-office | 1 | Once the eProcedure backoffice logic has assessed the notification and has concluded one or more evidences (or updates to evidences) need to be requested, the back-office should be able to send the evidence request to the OOP TS interface.
Please note, in case of multiple data owners in one Member State supporting the required evidence type, the Data evaluator needs to be aware which one to contact (as there is no possibility to ask the user). Hence, after processing the initial evidence in the intermediation pattern, it needs to store the data owner ('participant') to contact for updates. In the DBA pilot there will be only one data owner per Member State, so there is no need to store the participant at the DE. |
The evidence request will be the same or similar to the request of the intermediation pattern. |
| Back-office to OOP TS | no Lookup-specific requirements | ||
| DE4A connector | no Lookup-specific requirements | ||
| IDK | no Lookup-specific requirements | ||
| SMP | no Lookup-specific requirements | ||
| eDelivery Access Point | no Lookup-specific requirements | ||
| DNS & SML | no Lookup-specific requirements | ||
| Data service | no Lookup-specific requirements | ||
| Data source to OOP TS Interface | no Lookup-specific requirements |
The table below presents the requirements for the DE and DO mocks.
- The DE mock should mock the eProcedure Back-office Backend.
- The DO mock should mock the data service.
| Component | Nr | DBA requirement | Comment |
| DE mock | 1 | no Lookup-specific requirements
Same functionality as DE mock for Intermediation pattern. |
|
| DO mock | 1 | no Lookup-specific requirements
Same functionality as DO mock for Intermediation pattern. |
4.5 Component deployment
- See intermediation pattern.
Expectations for the semantic wokpackage of DE4A:
- analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)
Expectation for the technical workpackage in DE4A:
- double check to ensure the common components can be re-used from the intermediation pattern without any change.
4.6 Logical interfaces
The expected logical interfaces remain unchanged.
5 Solution architecture for Intermediation Pattern
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to D4.6 Pilot planning for this architecture (not included in the wiki yet).
The solution architecture remains unchanged, except for two additional requirements for the eProcedure portal that have been introduced by the S&N pattern.
| Component | Nr | DBA requirement | Comment |
| eProcedure portal | 1 | For the S&N pattern the logic of the eProcedure portal needs to be extended to initiate a subscription (start of S&N pattern). Whether a subscription is needed after processing the evidence is depending on the rules and regulation the data evaluator implements. | |
| 2 | For the S&N pattern the logic of the eProcedure portal might need to be adapted to include rules and texts for informing the user on subscriptions & possibly notifications.
As S&N is out of scope of the SDGR, this informative step is not part of the explicit request process. However, the user should be informed of subscriptions. |
Has no priority in piloting DBA S&N. Might be implemented by the DE, but it doesn't need to. |
6 Appendix: archimate component diagrams
6.1 Solution architecture for DBA authentication and powers validation
6.2 Solution architecture for Subscription & Notification pattern and Lookup pattern
TODO merge AC's and tailor to pilot increment 2.