DBA 2nd iteration Solution Architecture

Introduction

Approach: we follow the SA as was done for Intermediation (1st iteration).

iteration 2 IM = iteration 1 + SEMPER S&N and LKP not touched by SEMPER right?

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

Usage of eDelivery for both S&N and LKP patterns.

Design choices

Describe what WON'T be implemented for the pilot as well as design choices (see also scope section)

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. ref
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.ref

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

• 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 eIDASLegalpersonIdentifier). The DBA 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 eIDASLegalIdentifier to uniquely identify the company involved. This is a consequence of the pilot principle, that the authenticating proxy sends an eIDASLegalPersonidentifier 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, please see the DBA analysis on record matching ref

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. ref

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	- eProcedure portal - 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

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	Changes for 2nd iteration piloting
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.	Needs to be deployed by Member States for communicating fine grained powers. This component has been developed by the SEMPER project and needs to be deployed on the eIDAS node of each of the Member States. or implemented by MS as stated above?
Identity Provider	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 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. MMS 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 iteration MVP, this source must be used to verify full powers only. In the MVP 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 iteration MVP, 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.
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, 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. 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.	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.
eProcedure portal	DC specific The eProcedure portal handles all user interaction on the web. It connects to the national eIDAS node via the specific eIDAS connector. This requires the eProcedure portal to add the eIDAS login option to the login-webpage and interface to the specific eIDAS connector. As the DBA Pilot will use 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). The DBA login option should invoke the dedicated eIDAS connector instead of the regular one (a different URL).	In iteration 1 the eProcedure portal should request: authentication at LoA substantial the natural person attributes (at least the mandatory ones) the legal person attributes (at least the mandatory ones) In iteration 1 the eProcedure portal should: deny the user access in case of an “authentication failed”. grant the user access in case of an “authentication successful”. In iteration 2 the eProcedure portal should request: authentication at LoA substantial the legal person attributes only (at least the mandatory ones) request a powers validation on the applicable harmonised service In iteration 2 the eProcedure portal should: deny the user access in case of an “authentication failed” or "powers not sufficient" grant the user access in case of an “authentication successful” and "powers sufficient"
eIDAS connector	Common component (local deployment) The component Member States implement to connect to the eIDAS network as a relying party. The connector accepts authentication requests from the service providers of the Member State and forwards the requests to the Member States that needs to authenticate the user. After authentication, the eIDAS connector receives the authentication results and sends them to the requesting service provider (relying party). The eIDAS connector can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.	No changes in 2nd pilot iteration.
eIDAS proxy	Common component (local 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.

Requirements

The table below presents the requirements that the data evaluator and the authentication connector must implement.

Role	requirement	implement for pilot iteration 1	implement for pilot iteration 2
Data evaluator	The eProcedure portal adds an eIDAS login option for piloting.	x
	The eProcedure portal connects to a dedicated eIDAS pilot node.	x
	The eProcedure portal requests eIDAS legal person attributes (mandatory ones)	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	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
	MS implements SEMPER extension to the eIDAS connector.		x
	MS adapts the "specific eIDAS connector" to support powers validation requests and powers declarations		x
Authentication 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
	MS implements SEMPER extension to the eIDAS connector.		x
	MS adapts the "specific eIDAS proxy" to support powers validation requests and powers declarations		x
	Ms connects an IdP to the eIDAS proxy node for authenticating the natural person	x
	MS connects attribute provider (AP) to eIDAS node for eIDAS legal person attributes (in case not integrated in the MMS)	x
	MS connects mandate management system (MMS) to eIDAS node for validating full powers. Note: AP and MMS could be the same data source.	x
	Ms validates full powers	x
	MS adds fine-grained powers validation		x

Component Deployment

• eIDAS node 2.4 + SEMPER extension for node 2.4

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).

Component configuration

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

Interfaces

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

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

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.

File:2019-07-08 M3 Report on mandate attributes and solutions for cross-border mandate attributes - 1.0.pdf

DBA OOP TS solution

The solution for the OOP TS consists of all functionality of the OOP technical system. 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 with the familiar split in the different roles. It is a consolidated view of iteration 1 and 2, i.e. it covers all used patterns, i.e., IM, S&N and LKP.

In the next sections the process realizations, component descriptions, requirements, component implementations and expected logical interfaces are described.

OOP TS DBA

General Design Decisions

• 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. See Subscription and Notification Pattern and Lookup Pattern for more details.

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

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

Component description

The following table lists the components indicated in the image above. Per component a short decription of its use is given, by which role the component is used (i.e. DE, RDR, DT, DP) and whether the component is MS specific or common functionality.

Component	Short description of its use	Role	Genericness
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.	DR, DT	common
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.	DR, DT	both
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	common
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.	DR, DT	both
DE4A Connector	Taking care of eDelivery and IDK interfacing shielding DR and DT from complexities facilitating ease of implementation. Error handling and logging.	DR, DT	common
Authorization Controller	In case of LKP establish which data service, e.g. evidence types can be requested and whether this is allowed under allowed under applicable Union or national law without user request and preview. In case of S&N Is the DC allowed to subscribe? Is the DP allowed to send a notification?	DR, DT	common
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	both
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	both
Notification front-end	Application component providing the UI for civil servants to dispatch events and consult logging information for trouble shooting.	DO	both?
Data Service	The webservice of the data provider that will output the evidence requested.	DO	specific
eProcedure Portal	The eProcedure portal support the use of the cross-border evidence in the process (iteration 1). For both new patterns adaptations may be needed to the Portal, for instance when the eProcedure Back-office makes use of some of it's'functionality. TBD	DE	both?
eProcedure Portal Back-end	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).   Another change might be needed to support S&N and LKP patterns.	DE	both
eProcedure Back-office Backend	This component implements backend functionality like collecting relevant data for a subscription request, determining an appropriate response to request and updating logs. TBD is the required functionality is generic enough to justify a common component. Each DE needs to keep track of its subscriptions and needs some event handling asw ell.	DE	both?
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/owner can use the same (national) OOP protocols and services for cross-border use as well.	DE, DR	specific
Back-office to OOP TS	Interface	DE, DR	specific
Data source to OOP TS Interface	Interface for connecting the data service with the OOP TS (IM & LKP).	DO, DT	specific
Event handler to OOP TS Interface	Interface for connecting the OOP TS with the Cross-border Event Handler.	DO, DT	specific

Requirements

For DBA the Authorization Controller needs to check that only parties in the pilot send subscriptions and notifications.

In case of the lookup pattern (and possibler IM) the Authorization Controller checks if the vidence may be requested by DE.

The "list" from the service Notification Message and Subscriber List Preparation can be restricted to one party only.

For technical error messsages the existing WP5 list can be used. Business error messages in case of S&N TBD. For the pilot it is probably sufficient to establish the notification was received by DR (DT->DR).

Cross-border Event Handler

Subscription System: 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. TODO data model, operations, logical I/Fs.

A DC subscribes to the full set of cross-border events (the set is TBD).

There are two types of events, those that trigger an evidence update and those that don't. DBA needs support for a small set (5-6) of events containing both event types.

The Cross-border Event Handler could maybe be part of the Connector or at least be a common component. All DPs need this functionality.

The table below presents the requirements that the data evaluator and the authentication connector must implement.

Role	requirement	implement for pilot iteration 1	implement for pilot iteration 2
Data evaluator
Data requestor
Data transferor
Data owner

Component implementation

DNS, SML will be reused from iteration 1.

The Evidence service locator (ESL) configuration file probably needs to change. TBD

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

The DE4A Connector needs an update.

Various MS specific interffaces may be needed for (sub)system integration.

Both DE and DO need to do bookkeeping of subscriptions.

Both DE and DO need some sort of event handling.

Expected logical interfaces

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

We need to discuss with WP3/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 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
Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC	IN (from DE4A connector to ESL configuration file): -         Member state -         event type (e.g.DBA = business event) 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): -         subscription request/notification OUT (from eDelivery AS4 gateway to DE4A connector): -         ACK
DE4A Connector	subscription Initiating or changing subscription IN (from data evaluator to DE4A connector): - request ID (correlation) -         subject identifier (company in question) -         data owner identifier (DO id = participant ID) -         subscriber identifier (DE id = participant ID) -         event catalogue (DBA fixed business events) -         action 'subscribe'/'change subscription' -         (new) subscription start and end date OUT (from DE4A connector to DE): -         ACK (from DT) subscription confirmation DO -> DE IN -         request ID -         data owner identifier (DO id = participant ID) -         subscriber identifier (DE id = participant ID) -         status (success/fail) OUT - ACK notification IN (from data provider to DE4A connector): -         subscriber identifier (DE ID = participant ID) - data owner identifier (DO id = participant ID) -         Notification 1. catalogue event 2. event 3. timestamp event OUT (from DE4A connector to DR): -         ACK (from DR) lookup As in iteration 1.
...

Appendix: archimate component diagrams

OOP TS solution architecture

TODO merge AC's and tailot to MVP.