DBA 2nd iteration Solution Architecture

From DE4A
Jump to navigation Jump to search

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

This section contains the eIDAS solution architecture for the DBA pilot. The second pilot 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. This requires extension of eIDAS.

General design choices

The DBA eIDAS architecture has been designed with the following general design decisions:

  1. The DBA pilot will implement 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.
  2. 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.
  3. The DBA pilot will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.4.
  4. The DBA pilot will use 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 will be extended by the DBA pilot with:

  1. 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.
  2. Validating powers of representation. This function is not part of the eIDAS network currently.


Ad 1. Legal Person attributes & record matching at the DC

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 information on the company in eIDAS has been limited to attributes identifying the company. The eIDAS network lacks a possibility to specify the powers to validate though. Attributes specifying the powers (‘the powers declaration’) have not been defined yet. Implementing this option will require consensus on an additional processing rule: “In case of full powers, the eIDAS authentication will be successful and the data provider sends the eIDAS legal person attributes as well. In case of insufficient powers, the authentication must fail.”. Only that way the data consumer knows whether the user has full powers. By the lack of an explicit powers declaration, this option does not support fine-grained powers validation.

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 consumer additionally specifies the scope of the service the user needs powers for. After validating the powers, the data provider constructs a powers declaration confirming or denying the person’s powers. The extension allows for full powers validation as well as fine-grained validation. Furthermore, the extension adds attributes for specifying the powers, like the source of powers and one or more limitation to the use of the power.


Main design decisions regarding fine grained powers validation:

  1. the DBA pilot allows for representation of legal persons by natural persons only.
  2. the DBA pilot does not allow for intermediary parties (e.g. accounting firm operation on behalf of the company).
  3. the DBA pilot will operate a list of harmonised services to express the extent of powers. Non-harmonised services will not be supported.
  4. the DBA pilot will use the SDG annex II procedures as starting point for the list of harmonised services.
  5. the DBA pilot will implement fine grained powers using the SEMPER extension to eIDAS or implement the SEMPER concepts in custom eIDAS software.

For more information, please refer to the DBA internal discussion paper on Powers validation.

Component overview

Components for eIDAS powers validation.png

Process realisation

The table below presents the components that implement the application services for the DBA pilot.

table: process realisation
Process Application service Components
Request authentication, including powers validation Authentication initiation - 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 (optional) User authentication - Legal Person attribute provider
Provide authentication details, including powers declaration User authentication - Specific eIDAS proxy

- eIDAS proxy

- SEMPER extension

Component description

The SEMPER extension is the common component that the Member States need to deploy on their national eIDAS nodes. Instead of operating the SEMPER (reference) module, a custom extension that complies with the SEMPER specifications may be developed by the individual Member States as well.

table: component description
Component Short description of its use
SEMPER extension Common component (local deployment)

Component for extending the eIDAS connector and the eIDAS proxy to allow for explicit powers validation requests and powers declarations. This component has been developed by the SEMPER project and needs to be deployed on the eIDAS node of each of the Member States.

Mandate Management System Member State Specific

Member State specific solutions for registration and validation of powers. The Mandate Management Systems need to be connected to the national nodes for validating powers (if not connected already for validating full powers in the first iteration)

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. To enable fine grained powers validation, the specific eIDAS connector needs to be extended for requesting powers validation alongside authentication.

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. 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 MMS in national protocol, receive and interpret the response from the MMS and translate it back to cross-border taxonomy.


Requirements

Describe the requirements for application services.

Component Implementation

eIDAS node 2.4 + SEMPER extension

or allow

eIDAS node 2.5? No compatible SEMPER extension available (check with TUG).


Proposal for the harmonised services to express powers cross-border:

table: harmonised services for cross-border validation of powers
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
SDGR+ 1 Starting of a company or opening as branch
SDGR+ 2 Initial registration of a business activity with the business register

Expected logical interfaces

The request will be a combination of a regular eIDAS request (not new) and a powers validation request (new).


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:
    • 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

Details specified by the SEMPER project in deliverable M3.

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.

Shared solution OOP TS

Image might need an update, i.e. depict S&N and LKP shared stuff

Shared solution

The OOP TS domain (WP5) provide the data requestor and data transferor with the components needed for

  1. cross-border subscription and notification messages
  2. 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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Validate subscription request (DP)
  • eSignature Validation Service
  • Message Decryption
  • Authority Check
  • Authorization Controller
  • Trust Service Provisioning
  • Data Encryption/Decryption
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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Forward confirmation (DC) n/a
Log subscription information (DC) n/a

Registering the subscription at DP and logging subscription at DC is similar in functionality but mirrored. This could be common component (reference implementation) or at least a specification. This component would be optional for MS to use.

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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Validate event notification (DC)
  • eSignature Validation Service
  • Message Decryption
  • Authority Check
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Determine event response (DC) Event Evaluation eProcedure Back-office Backend
Request change of subscription (DC)
  • Notification Mismatch Signal
  • Update Notification Response Log
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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Evaluate evidence request (DP)
  • eSignature Validation Service
  • Message Decryption
  • Data Exchange Service
  • Authority Check
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Establish subject identity (DP) Identity/Record Matching Record Matching

(needed for company matching right?)

Communicate non-availability of OOP (DP)
  • Error Handler
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Extract evidence (DP) Evidence Lookup Evidence Query
Communicate non-availability or Delay of evidence (DP)
  • Error Handler
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
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)
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Forward evidence (DC)
  • eSignature Validation Service
  • Message Decryption
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
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

DBA OOPTA Shared.png

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 Issuing Authority Locator (IAL) TBC Change w.r.t. iteration1? There is no evidence lookup, instead the endpoint where to send the subscription request to is needed. ALso there is no evidence response, it is event oriented now.

As the DBA pilot’s MVP uses just one type subscription message with just one data provider per Member state (on NUTS0 level), there is no need for dynamic discovery of the data provider. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (member state and participant id) like in iteration 1.

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. 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 probably needs to change. TBC

SMP, eDelivery AS4 gateway will be reused from iteration 1.

The DE4A Connector needs an update.

Component Expected interface
Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC IN (from DE4A connector to ESL configuration file):

-         Member state

-         ... more?

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

-         Subscription Request

-         Data providing Member state

OUT (from DE4A connector to data evaluator):

-         Data providing member state

-         Data provider

-         Subscription Response

Expected logical interfaces

The expected logical interfaces are expected to remain largely the same.

We need to discuss with WP5 the implementation of the Data Service Lookup ABB. Right now this is covered by two SBBs ESL and IAL. However, for S&N there is no evidencen lookup or exchange, so at lest the name is off. Also the I/F with the Connector changes slightly. In the table above some differences are indicated.

DC-specific solution

The DC specific solution is different for every DC and the 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.

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
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Exception: Forward subscription error n/a
Exception: Investigate reason for subscription error n/a
Forward confirmation n/a
Log subscription information n/a could be acommon component
Notification
Process Application Service Components
Validate event notification
  • eSignature Validation Service
  • Message Decryption
  • Authority Check
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Determine event response Event Evaluation eProcedure Back-office Backend

another candidate for reuse TBC

Request change of subscription
  • Notification Mismatch Signal
  • Update Notification Response Log
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
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Establish non-availability of OOP Evidence Request Tracker Evidence Interchange Back-end
Forward evidence
  • eSignature Validation Service
  • Message Decryption
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Evaluate evidence Requirements/Evidence Matching eProcedure Rules Engine

<<insert updated diagram>>

DBA DC Specific.png

Component description

Additional components may be possible on DC side TBD

Also, it is likely not be be handled by the eProcedure portal but from the back office.

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
  • eSignature Validation Service
  • Message Decryption
  • Authority Check
  • Authorization Controller
  • Trust Service Provisioning
  • Data Encryption/Decryption
Evaluate subscription request Subscription Evaluation Subscription System
Exception: Prepare subscription error message Subscription Error Handling Subscription System
Exception Send subscription error message
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Register subscription Subscription Creation and Update Subscription System
Confirm subscription Subscription Confirmation Subscription System
Send subscription confirmation
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
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
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Lookup
Process Application Service Component
Evaluate evidence request
  • eSignature Validation Service
  • Message Decryption
  • Data Exchange Service
  • Authority Check
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Establish subject identity Identity/Record Matching Record Matching

(needed for company matching right?)

Communicate non-availability of OOP
  • Error Handler
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Extract evidence Evidence Lookup Evidence Query
Communicate non-availability or Delay of evidence
  • Error Handler
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange
Compose evidence response Domestic to Cannonical Evidence Transformation Evidence Portal Back-end
Transfer evidence
  • Message Encryption
  • e-Signature Creation Service
  • Data Exchange Service
  • Trust Service Provisioning
  • Data Encryption/Decryption
  • Data Exchange

<<insert updated diagram>>

DBA DP Specific.png

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.