Difference between revisions of "DBA 2nd iteration Solution Architecture"
m (added first texts for Powers validation.) |
|||
Line 23: | Line 23: | ||
== DBA eIDAS solution == | == DBA eIDAS solution == | ||
+ | ''[so far mainly the 2nd iteration specifics have been included in the wiki. It might be worthwhile to create a stand-alone and full version of the solution architecture here - including texts and diagrams from iteration 1 SA that remain unchanged]'' | ||
+ | |||
+ | |||
+ | This section contains the eIDAS solution architecture for the second pilot iteration of the DBA pilot. The second iteration adds fine grained powers validation to eIDAS and will be used in conjunction with the intermediation pattern. While the first iteration solution architecture supports full powers only, the second iteration allows for explicit expression of powers in a powers validation request and powers declaration. | ||
+ | [[File:EIDAS roles.png|center|frame]] | ||
+ | Main design decisions regarding fine grained powers validation: | ||
+ | |||
+ | # the DBA pilot allows for representation of legal persons by natural persons only. | ||
+ | # the DBA pilot does not allow for intermediary parties (e.g. accounting firm operation on behalf of the company). | ||
+ | # the DBA pilot will operate a list of harmonised services to express the extent of powers. Non-harmonised services will not be supported. | ||
+ | # the DBA pilot will use the SDG annex II procedures as starting point for the list of harmonised services. | ||
+ | # the DBA pilot will implement fine grained powers using the SEMPER extension to eIDAS or implement the SEMPER concepts in custom eIDAS software. | ||
+ | |||
+ | Proposal for the harmonised services to express powers cross-border: | ||
+ | {| class="wikitable" | ||
+ | |+ | ||
+ | !Catalogue | ||
+ | !Harmonised service | ||
+ | |- | ||
+ | |SDGR | ||
+ | |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 | ||
+ | |Registration of an employer (a natural person) with compulsory pension and insurance schemes | ||
+ | |- | ||
+ | |SDGR | ||
+ | |Registration of employees with compulsory pen�sion and insurance schemes | ||
+ | |- | ||
+ | |SDGR | ||
+ | |Submitting a corporate tax declaration | ||
+ | |- | ||
+ | |SDGR | ||
+ | |Notification to the social security schemes of the end of contract with an employee, excluding procedures for the collective termination of employee contracts | ||
+ | |- | ||
+ | |SDGR | ||
+ | |Payment of social contributions for employees | ||
+ | |- | ||
+ | |SDGR+ | ||
+ | |Starting of a company or opening as branch | ||
+ | |- | ||
+ | |SDGR+ | ||
+ | |Initial registration of a business activity with the business register | ||
+ | |} | ||
+ | |||
+ | |||
+ | eIDAS attributes to request: | ||
+ | |||
+ | * legal person attributes (at least the mandatory ones) | ||
+ | |||
+ | |||
+ | eIDAS attributes to respond with: | ||
+ | |||
+ | * legal person attributes (at least the mandatory ones) | ||
+ | * representative natural person attributes (at least he mandatory ones) | ||
=== Shared solution === | === Shared solution === |
Revision as of 13:26, 3 August 2021
Introduction
Approach: we follow the SA as was done for Intermediation (1st iteration).
Working on thr SA I realize that the SA for iteration 1 might need an update as well... TBC
Scope and focus
- Within scope
- Modify DO/DE Mocks for S&N en Lookup patterns
- Common component voor Cross-border subscriptions (optional for MS to use, i.e. not mandatory)
- Event Notification + Evidence Lookup flavour, in line with PSA 2nd iteration
- Outside scope
- Resend a subscription request in case of an error (instead the possibility to inspect the logs and manually resend a request is deemed sufficient (MVP))
- Include the Evidence in the notification (instead pure notification + lookup)
- Attribute Lookup
DE4A preconditions
Design choices
Describe what WON'T be implemented for the pilot as well as design choices (see also scope section)
eIDAS and OOP TS
DBA eIDAS solution
[so far mainly the 2nd iteration specifics have been included in the wiki. It might be worthwhile to create a stand-alone and full version of the solution architecture here - including texts and diagrams from iteration 1 SA that remain unchanged]
This section contains the eIDAS solution architecture for the second pilot iteration of the DBA pilot. The second iteration adds fine grained powers validation to eIDAS and will be used in conjunction with the intermediation pattern. While the first iteration solution architecture supports full powers only, the second iteration allows for explicit expression of powers in a powers validation request and powers declaration.
Main design decisions regarding fine grained powers validation:
- the DBA pilot allows for representation of legal persons by natural persons only.
- the DBA pilot does not allow for intermediary parties (e.g. accounting firm operation on behalf of the company).
- the DBA pilot will operate a list of harmonised services to express the extent of powers. Non-harmonised services will not be supported.
- the DBA pilot will use the SDG annex II procedures as starting point for the list of harmonised services.
- the DBA pilot will implement fine grained powers using the SEMPER extension to eIDAS or implement the SEMPER concepts in custom eIDAS software.
Proposal for the harmonised services to express powers cross-border:
Catalogue | Harmonised service |
---|---|
SDGR | 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 | Registration of an employer (a natural person) with compulsory pension and insurance schemes |
SDGR | Registration of employees with compulsory pen�sion and insurance schemes |
SDGR | Submitting a corporate tax declaration |
SDGR | Notification to the social security schemes of the end of contract with an employee, excluding procedures for the collective termination of employee contracts |
SDGR | Payment of social contributions for employees |
SDGR+ | Starting of a company or opening as branch |
SDGR+ | Initial registration of a business activity with the business register |
eIDAS attributes to request:
- legal person attributes (at least the mandatory ones)
eIDAS attributes to respond with:
- legal person attributes (at least the mandatory ones)
- representative natural person attributes (at least he mandatory ones)
Process realisation
Mapping processes/activities to application services and components (PSA --> tables).
Component description
Classify components: DE/DO/Common component.
Requirements
Describe the requirements for application services.
Component Implementation
Describe the implementation of the components.
Expected logical interfaces
Describe the (logical) interfaces between the components.
DC specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DP specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DBA OOP TS solution
Maybe this is the place to insert explanation of the subscription application collaboration (and notification?), i.e. front-end/back-end w.r.t. notifications.
The shared solution for the OOP TS consists of all common functionality of the OOP technical system. Most of the common OOP TS components need to be implemented by the data requestor and data transferor, although the OOP TS uses central components as well.
Image might need an update, i.e. depict S&N and LKP shared stuff
The OOP TS domain (WP5) provide the data requestor and data transferor with the components needed for
- cross-border subscription and notification messages
- performing the lookup of an evidence
In the MVP the DBA pilot uses one type of subscription message and one type on 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 (WP3). There will be just one data provider per Member state: the business register, where the subscription will be recored and where the cross border events are generated, i.e.is the authentic source of company information. The DC will subscribe in one Member State at a time. The DP will notify one Member State at the time. The explicit request and the preview functions won't be needed, in both interaction patterns there is no user involvement.
Process realisation
The table below presents the components that implement the application services for the DBA pilot. The process realization is dealt with per pattern with S&N split in two as they are independently triggered.
Subscription
Process | Application Service | Components |
Initiate subscription (DC) | Subscription Initiation | eProcedure Back-office Backend |
Change subscription (DC) | Subscription Initiation | eProcedure Back-office Backend |
Lookup event provider routing information (DC) | Inquire Routing Information | Data Service Lookup |
Send subscription request (DC) |
|
|
Validate subscription request (DP) |
|
|
Evaluate subscription request (DP) | Subscription Evaluation | Subscription System |
Exception: Prepare subscription error message (DP) | Subscription Error Handling | Subscription System |
Exception Send subscription error message (DP) |
|
|
Exception: Forward subscription error (DC) | n/a | |
Exception: Investigate reason for subscription error (DC) | n/a | |
Register subscription (DP) | Subscription Creation and Update | Subscription System |
Confirm subscription (DP) | Subscription Confirmation | Subscription System |
Send subscription confirmation (DP) |
|
|
Forward confirmation (DC) | n/a | |
Log subscription information (DC) | n/a |
Notification
Process | Application Service | Components |
Identify event (DP) | Cross-border Event Filter | Cross-border Event Handler |
Check subscriptions (DP) | Subscription Lookup | Subscription System |
Prepare notification message and subscriber list (DP) | Notification Message and Subscriber List Preparation | Cross-border Event Handler |
Exception: Resend past events (DP) | Manual Event Dispatch | Notification Front-end |
Resolve service metadata (DP) | Inquire Routing Information | Data Service Lookup |
Exception: Resolve subscriber participant ID and inform National Contact Point (DP) | Subscription Mismatch Log | Notification Front-end |
Send event notification (DP) |
|
|
Validate event notification (DC) |
|
|
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 |
Lookup
Note: compared with Intermediation the user is absent.
Process | Application Service | Component |
Determine required cross-border evidence (DC) | Cross-border Evidence Matching | Evidence Type Translator |
Lookup routing information (DC) | Inquire Routing Information | Data Service Lookup |
Request evidence (DC) |
|
|
Evaluate evidence request (DP) |
|
|
Establish subject identity (DP) | Identity/Record Matching | Record Matching
(needed for company matching right?) |
Communicate non-availability of OOP (DP) |
|
|
Extract evidence (DP) | Evidence Lookup | Evidence Query |
Communicate non-availability or Delay of evidence (DP) |
|
|
Establish non-availability of OOP (DC) | Evidence Request Tracker | Evidence Interchange Back-end |
Compose evidence response (DP) | Domestic to Cannonical Evidence Transformation | Evidence Portal Back-end |
Transfer evidence (DP) |
|
|
Forward evidence (DC) |
|
|
Evaluate evidence (DC) | Requirements/Evidence Matching | eProcedure Rules Engine |
<<insert updated diagram>>
Do we stick with the ESL config file or will IDK implement something?
There might be a common components @DO and @DE for S&N TBC
Component description
The following table lists the shared components indicated light blue in the image above.
Component | Short description of its use |
Evidence service locator (ESL) configuration file | 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). |
SMP | 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 info. |
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. |
eDelivery AS4 gateway | 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. |
Requirements
TODO
Component implementation
DNS, SML will be reused from iteration 1. The
Evidence service locator (ESL) configuration file TBC
SMP, eDelivery AS4 gateway will be reused from iteration 1.
The DE4A Connector needs an updateTBC.
Component | Expected interface |
Evidence service locator (ESL) configuration file | IN (from DE4A connector to ESL configuration file):
- Member state - Canonical evidence type OUT from ESL configuration file to DE4A connector): - participant ID |
SMP | IN (from DE4A connector to SMP):
- Participant ID OUT (from SMP to DE4A connector): - Service URL - Certificate to use |
DNS & SML | IN (from DE4A connector to DNS):
- Member state - Participant ID OUT (from DNS to DE4A connector): - SMP location |
eDelivery AS4 gateway | IN (from DE4A connector to eDelivery AS4 gateway):
- evidence request OUT (from eDelivery AS4 gateway to DE4A connector): - Evidence response |
DE4A Connector | IN (from data evaluator to DE4A connector):
- Data evaluator - Data evaluating Member state - Requested evidence type - Company identification (eIDASLegalPersonID, eIDASLegalName) - Data providing Member state
OUT (from DE4A connector to data evaluator): - Data providing member state - Data provider - Evidence type - Company identification (eIDASLegalPersonID, eIDASLegalName) - Evidence (XML) |
Expected logical interfaces
The expected logical interfaces are expected to remain the same. The implementation of ESL might change (from configuration file to WP3 implementation?). The Connector needs to be studied, i.e. what are the changes needed for S&N and LKP?
DC-specific solution
The DC specific solution is different for every DC. The DC specific solution architecture will be specified in the design document of the pilot processes (one for each data consumer). Nonetheless the DC-specific solution at a higher level of abstraction show similarities.
The DC specific architecture consists of the evaluator and requestor specific services. The requestor specific services are typically implemented at Member state level.
Process realization
Subscription
Process | Application Service | Components |
Initiate subscription | Subscription Initiation | eProcedure Back-office Backend |
Change subscription | Subscription Initiation | eProcedure Back-office Backend |
Lookup event provider routing information | Inquire Routing Information | Data Service Lookup |
Send subscription request |
|
|
Exception: Forward subscription error | n/a | |
Exception: Investigate reason for subscription error | n/a | |
Forward confirmation | n/a | |
Log subscription information | n/a |
Notification
Process | Application Service | Components |
Validate event notification |
|
|
Determine event response | Event Evaluation | eProcedure Back-office Backend |
Request change of subscription |
|
eProcedure Back-office Backend |
Dismiss event | Update Notification Response Log | eProcedure Back-office Backend |
Trigger evidence lookup | Update Notification Response Log | eProcedure Back-office Backend |
Notify Responsible Organization | Update Notification Response Log | eProcedure Back-office Backend |
Lookup
Process | Application Service | Component |
Determine required cross-border evidence | Cross-border Evidence Matching | Evidence Type Translator |
Lookup routing information | Inquire Routing Information | Data Service Lookup |
Request evidence |
|
|
Establish non-availability of OOP | Evidence Request Tracker | Evidence Interchange Back-end |
Forward evidence |
|
|
Evaluate evidence | Requirements/Evidence Matching | eProcedure Rules Engine |
<<insert updated diagram>>
Component description
Additional components may be possible on DC side TBD
Component | Short description of its use |
eProcedure portal | The eProcedure portal should be adapted to support the use of the cross-border evidence in the process. For that purpose it should facilitate the user in the OOP-process and connect to the OOP TS. Connection to the OOP TS is typically implemented via a Portal-to-OOP TS-interface that may utilise national OOP-protocols and infrastructure. |
eProcedure backend | The eProcedure backend handles all eProcedure specific logic. For the DBA pilot this backend functionality basically remains unchanged. One addition to the backend may be the record matching on the company (for companies registered prior to the pilot). |
Portal to OOP TS interface | Member states may (but do not need to) implement an interface from national OOP protocols to the DE4A data model (DE4A connector). Such an interface guarantees that the data evaluator can use the same (national) OOP protocols and services for cross-border use as well. |
Requirements
TODO
Component implementation
This section is fully DC-specific.
Expected logical interfaces
This section is fully DC-specific.
DP-specific solution
The DP specific solution is different for every DP. The DP specific solution architecture will be specified in the design document of the pilot processes (one for each data consumer). Nonetheless the DP-specific solution at a higher level of abstraction show similarities.
The DP specific architecture consists of the owner and transferor specific services. The transferor specific services are typically implemented at Member state level.
Process realisation
Subscription
Process | Application Service | Components |
Validate subscription request |
|
|
Evaluate subscription request | Subscription Evaluation | Subscription System |
Exception: Prepare subscription error message | Subscription Error Handling | Subscription System |
Exception Send subscription error message |
|
|
Register subscription | Subscription Creation and Update | Subscription System |
Confirm subscription | Subscription Confirmation | Subscription System |
Send subscription confirmation |
|
|
Notification
Process | Application Service | Components |
Identify event | Cross-border Event Filter | Cross-border Event Handler |
Check subscriptions | Subscription Lookup | Subscription System |
Prepare notification message and subscriber list | Notification Message and Subscriber List Preparation | Cross-border Event Handler |
Exception: Resend past events | Manual Event Dispatch | Notification Front-end |
Resolve service metadata | Inquire Routing Information | Data Service Lookup |
Exception: Resolve subscriber participant ID and inform National Contact Point | Subscription Mismatch Log | Notification Front-end |
Send event notification |
|
|
Lookup
Process | Application Service | Component |
Evaluate evidence request |
|
|
Establish subject identity | Identity/Record Matching | Record Matching
(needed for company matching right?) |
Communicate non-availability of OOP |
|
|
Extract evidence | Evidence Lookup | Evidence Query |
Communicate non-availability or Delay of evidence |
|
|
Compose evidence response | Domestic to Cannonical Evidence Transformation | Evidence Portal Back-end |
Transfer evidence |
|
|
<<insert updated diagram>>
Component description
Component | Short description of its use |
Data service | The webservice of the data provider that will output the evidence requested. |
Portal to OOP TS interface | Member states may (but do not need to) implement an interface from national OOP protocols to the DE4A data model (DE4A connector). |
Requirements
TODO
Component implementation
This section is fully DP-specific.
Expected logical interfaces
This section is fully DP-specific.
Appendix: archimate component diagrams
DBA eIDAS solution architecture
OOP TS solution architecture
TODO merge AC's and tailot to MVP.