DE4A - User contributions [en-gb]

Goals and success criteria

2022-02-09T13:54:41Z

Bart.vanbekkum: typos and minor changes

[[Doing Business Abroad Pilot|Back to Doing Business Abroad main page]]

[[DBA D4.7 Initial Running Phase Report|Back to main page of D4.7 Initial Running Phase Report]]

[[Current status of pilot|Back to Previous Chapter: 2. Current Status of Pilot]]

[Work in progress]

== 3.1 Introduction ==
The analyses conducted with regards to challenges that the implementation of the SDGR introduces, as wel as the realization of the infrastructure implementing the SDGR and conclusions of these analyses, proved very fruitful. This chapter summarizes the lessons learned form these activities, and provides suggestions for the implementation and adoption of the SDGR implementation.

==3.2 Learning towards Adoption==

==== ''3.2.1 Lessons learned from analysing and designing national integration of cross-border OOP'' ====
{| class="wikitable" style="width: 80%;"
! style="width: 2%" |ID
! style="width: 10%" | Topic
! style="width: 33%" |Suggestions for adoption
! style="width: 55%" | Lessons learned
|-
|1
|Design process
|DBA advises Member States to invest time to bring together the eIDAS and OOTS knowledge. This requires organising and prioritising as this knowledge is scarce.
|Designing national integration required in-depth knowledge of both eIDAS and OOTS. This knowledge (specifically the combination of both) is not broadly available in Member States. Knowledge of both domains should be brought together in order to prevent designs based on false assumptions of the other domain.
|-
|2
|Scoping
|DBA advises the European Commission and Member States not to solve all user scenario's at once, but to focus on the most frequently used ones. Please focus on core functionality. And at the same time organise follow-ups on improvements and additions to address later on.
|The project ran into many complex topics that needed to be solved in the pilot design phase. The pilot lead has organised a series of meetings to discuss these topics.
To keep focus at the core research questions and to limit resources needed, the pilot partners agreed to simplify whenever adequate, e.g. focussing at most important evidence type instead of all possible types, accepting request for one single evidence type at the time (instead of allowing requests for multiple evidence types), limiting to full powers validation to start with. The pilot secured progress and focus by scoping strictly.
|-
|3
|Company representation
|DBA advises the European Commission to clarify in advance which version of the eIDAS specification should be implemented for the SDGR to prevent incompatibility between Member States.
|Use of eIDAS including legal entity attributes (company representation) is not widespread in the EU. Currently, there are just two eID scheme's notified including legal person attributes. For piloting the partners set up a pilot network of eIDAS nodes including legal person attributes to allow for piloting eProcedures for companies. In preparing for the pilot, Member States turned out to communicate company representation in different ways. Especially regarding the use of the eIDAS representative attributes (representative prefix). Furthermore, during pilot preparation eIDAS node 2.4 became available. This version of the CEF reference software enforced the eiDAS 1.2-specification that turned out to be in conflict with the agreed use of eIDAS attributes in the DBA pilot. The eIDAS 1.2 specification regarding representation is not necesarilly backwards compatible. As a result, this raised additional confusion and led to inconsistent deployments.
|-
|4
|Powers validation
|DBA advises Member States to focus at implementing full-powers validation flows to start with. Adding more fine grained powers validation is required for 100% implementing the eProcedures, but also requires a more advanced solution.

Furthermore, DBA advises the European Commission to facilitate validating full-powers using the currently available eIDAS. This requires an additional policy rule (please see DBA design documentation regarding this topic).
|Validating full powers has been proven to be a first (and good) step in implementing cross-border OOP for businesses (requiring company representation). It allows for moving ahead with eIDAS as is available today and seems fitting for SME's (it will be an official representative initiating business abroad most of the time).

|-
|5
|Record matching
|DBA advises Member States to use the national company ID's as eIDASLegalIdentifiers when extending the pilot to SDG-wide implementation.
|The pilot partners agreed to provide the national company registry numbers as eIDASLegalIdentifier in the authentication flow (eIDAS authentication proxy role). This diminished the need to do record matching on companies at the data owner. There was no substantial need to do record matching on the natural person by the data owners of the DBA pilot.
|-
|6
|Explicit request
|DBA advises data evaluators to integrate (1) request to consent and (2) explicit request into one joint question to the user to prevent adding to the confusion - of course in case both are applicable at the same time.
|In some cases, users need to express consent for the retrieval of attributes (GDPR). In almost all cases when using the OOTS, the user needs to express explicit request (SDGR). Although legally sound, in practise the difference between both is difficult to understand for data evaluators. DE's furthermore expect that users will ignore such requests and just click "ok".
|-
|7
|Multiple-MS scenario's
|DBA advises Member States to start SDG-implementation with the simplest interaction patterns involving just two Member States.
|Three- or multiple Member State scenario's tend to get really complex, requiring disproportionate resources to analyse, design and implement. An example of a 3 MS-scenario would be a natural person (representative) from MS A, representing a legal person (represented) from MS B, based on a mandate registered in MS B, to apply for a service form a SP in MS C.
|-
|8
|eIDAS non-notified eID
|DBA advises The European Commission and the Member States without notified eID's to agree on a temporarily solution for using non-notified eID's in SDG-procedures.
|Most of the participating Member States dind't operate a notified eID at the moment of piloting. On a bilateral basis non-notified eID's were accepted for piloting purposes, although pilot partners expressed their doubts regarding acceptance of non-notified eIDs for large scale SDG. Notification of eID's is a strong prerequisite for implementing SDG. Mandatory eID-notification as expected under the new eIDAS regulation (eIDAS revision) will not be in time for SDG-implementation.
|-
|9
|Sector specific systems
|Integration of the OOTS with sectoral systems (BRIS in this pilot) has proven to be not so straight forward as many expected at the start of the project.
|For the DBA pilot alignment to - or integration with - BRIS has been an important topic from the start of the project. Much time has been spent on workshops, desk research and analysis. In the end, re-use of BRIS has been limited to semantics. Re-use of information flows, building blocks, etc. was not possible due to difference in legal framework, governance, authorities involved, solution implemented, etc.The solutions have been developed for different purposes and hence are not easily aligned.
|-
|10
|User interaction design
|DBA advises the European Commission to provide wireframes in order to have generic steps (like Explicit Request and Preview) implemented in a similar way in all MS.
|Several data evaluators needed to implement the same logic in their specific systems, including user iteraction (general explanation, explicit request, preview). The user interaction design across participating Member States turned out to show some differences in informative texts, detail of explanation, use of buttons, etc. This may lead to confusion for the user that deals with multiple data evaluators as well as a slow learning curve. DBA decided to provide a pilot-wide reference in the form of wireframes to allow for more uniformity across the pilot.
|}

==== ''3.2.2 Lessons learned from implementing and testing the DE4A OOTS'' ====
{| class="wikitable" style="width: 80%;"
! style="width: 2%" |ID
! style="width: 10%" | Topic
! style="width: 33%" |Suggestions for adoption
! style="width: 55%" | Lessons learned
|-
|1
|Planning and organising tasks
|DBA advises to allocate a multi-month phase for establishing alignment, priorities, financial means etc. for all organizations involved.

Furthermore, it is necessary to have a coordinating team (equipped with sufficient knowledge about the solution) in each Member State to make sure that legal, semantical, technical and managerial issues are being resolved in a timely manner.
|The components to be used (in the pilot) were distributed over several authorities in a Member State, requiring the commitment from all authorities. This commitment is not obvious and must be secured beforehand. Also, as the systems are distributed, the teams working on the systems are distributed as well. Collaboration took more time and in each team, priorities were a continuous battle.
|-
|2
|Handing over
|DBA advises the European Commision to put additional efforts in explaining the workings of the SDG OOTS components to public authorities involved. The better the solution is understood by all, the smooher the SDG implementation will be.
The national complexity that the SDG imposes on Member States (e.g. record matching) is easily underestimated.
|Design documents and specification have sometimes been interpreted by different pilot partners in different ways. During preperation of the pilot or during interoperability testing such differences surfaced. It would be better to have a detailled common understanding of all the design details prior to the testing phase. Take the time for handing over Solution Architecture to WP3 and 5, and make sure that everything is understood.
|-
|3
|Documenting
|DBA advises the European Commission to invest in proper and clear documentation for developers in Member States, so they can get the OOTS up and running with as less as possible efforts. Documentation should not be too cryptic and short, but definately also be not too extensive. Feedback on the documentation from first movers has proven to be very useful in the DBA pilot.
Additionally, installing a small central team of technical experts providing support technical experts fin Member States, could be considered.
|For developers of the common components, there's a lot of logic behind its internal logic, structure, configuration, etc. Deploying these components by the Member States in the DBA pilot raised several questions regarding the use of Docker images, configuration items that needed to be set correctly, required firewall and DNS settings, etc. Things were not always as straight forward as expected.
|-
|4
|Configuring
|DBA advises Member States to prepare for the steps to be taken to request the certificates needed to operate the OOTS.
DBA advises the European Commission to investigate whether the process for acquiring the OOTS certificates can be simplified.

DBA advises the European Commission to design a procedure for communication between Member States in case of change of certificates and to provide for certificate-rollover to guarantee OOTS-connectivity.
|The components needed for SDG rely heavily on use and exchange of certificates for server authentication, signing, etc. The process of acquiring the certificates turned out to be time-consuming and error-prone (all details must be in place when requesting the certificates). Furthermore, the procedure of requesting certificates is regulated in a way it requires signatures of responsible people within the requesting institution that do not on a daily basis work with - and understand the use of - certificates. Or people that are not available imidiately (company executives).
|-
|5
|Integrating DE and DO
|DBA advises Member States to take impact on existing systems into account. Including the backlog of items that might need to be resolved before being able to connect to the OOTS.
|
When integrating to the DT/DR, expect to run into existing problems in the DO/DE systems that need resolving as well. This will create extra work, although the work is not directly being created due to integration with the DT/DR. The problems in the DE/DO systems were existing already, but were not causing real issues until then (problems were accepted) but might need to be resolved in order to achieve good integration to the DT/DR.
|-
|6
|Interopability testing
|Wider OOTS implementation requires more inter-Member State coordination regarding exchange of connectivity details, configuration and cross-border interoperability testing. Planning of these activities requires much attention and flexibility from the Member States. DBA advises to take this into account when connecting the decentralised SDG OOTS components. We refer also to the eIDAS lessons learned with regards to exchange fo certificates etc.
|The speed of development varies per Member State. Therefore readiness for cross-border testing (and piloting, for that matter) is also distributed in time. MS A can have their DE ready months before MS B has (due to several national impediments). Testing on fixed moments in time for all DEs and all DOs has proven not realistic, as does starting pilots at one moment in time.
|-
|7
|Interopability testing
|Establish clear readiness criteria for DE/DO DE4A Connector before starting connectathons.
|The DBA pilot has proven that a lot of settings need to be configured correctly to allow succesful cross-border evidence exchange. During interoperability testing (connecthatons) Member States sometimes had different views on what components or parameters had to be set in order to start testing. As a result, not in all cases the complete flow could be tested at once.
|-
|8
|Interoperability testing
|DBA advises the European Commission to coordinate exchange of test credentials between Member States. Many-to-many "requesting and sending of eID's on a bilateral basis" should be prevented.
|Proper interoperability testing is only possible with the required test eID means. These national eID means have not always been easily available (depending on the MS-specific situation - dependancies on IdP's may exist). This hindered cross-border interoperability testing at some occasions. The effect of lacking test credentials will be much greater in case of large scale implementing the SDGR.
|-
|9
|Reliance on eIDAS
|DBA advises the Member States to setup and test national eIDAS deployment prior to implementing the SDGR, to prevent this delaying SDGR.
|DBA pilotting - just as SDG implementation - relies on use of eIDAS. Unfortunately, eIDAS is not fully up and running in all Member States. In preparing for the DBA pilot, Member States had to setup eIDAS as well (pilot network of eIDAS nodes). In interoperability testing, several eIDAS related setup-issues needed to be solved.
|-
|10
|SDG implementing acts
|DBA advises the European Commission and Member States to be aware no such thing as 'a final version' exists in the area of inter-Member State information exchange. Moving forward step-by-step with versions currently available is crucial to progress. Note that continuous alignment with all European initiatives during single steps is not feasible and will delay each initiative started.
|DBA pilot implementation has been delayed by numerous discussions (within Member States and between Member States) on alignment with the SDG OOTS that was being sketched at the same time. Although this approach had been deliberately chosen and agreed upon at the start of the DBA project (to enable real piloting and provide input to SDG), in practise discussions were raised over and over again and caused prioritization challenges for the pilot activities of partners. 
|-
|11
|Cooperation
|DBA advises to facilitate technical experts of the Commission and the Member States to easily ask each other questions, respond, etc. using a tool for this purpose, e.g. Slack.
|Slack seems to be a good means to have developers of different MS / WPs collaborate.
|}

==== ''3.2.3 Technical, semantic and organisational/legal knowledge provided to other WPs'' ====
*

*
*
{| class="wikitable" style="width: 80%;"
!style="width: 2%"|ID
!style="width: 10%"| Topic
! style="width: 33%" |Suggestions for adoption
! style="width: 55%" | Lessons learned
|-
|1
|Communication
|Use visual tools to show the benefits of OOP to users, e.g. presentations and videos.

Prepare the creation of an animation by setting up a good storyline and slides that illustrate the flow of the animation.
|Implementation of the Oncle Only Principle might be interpreted as abstract by users / companies that might benefit from it. From a user perspective, there's not too much to see in the OOP-process. OOP might be interpreted as 'not a big deal' by the user. Large parts of the solution are "complexity under the hood". Hence, additional efforts are needed to explain in an understandable way the hugh difference that OOP makes.
|}

==== ''3.2.4 Pilot learning for Sustainable impact and new governance models'' ====
{| class="wikitable" style="width: 80%;"
! style="width: 2%" |ID
! style="width: 10%" | Topic
! style="width: 33%" |Suggestions for adoption
! style="width: 55%" | Lessons learned
|-
|1
|Harmonisation
|DBA advises the European Commission to organise the harmonisation process of services for cross-border powers validation (see SEMPER project results and DBA pilot for sample harmonisation).
|For fine-grained powers validation, Member States need to agree on a harmonised set of services. In the DBA pilot: the SDG procedures of annex II to start with.
|-
|2
|Harmonisation
|DBA advises the European Commission to organise the harmonisation process of event types for cross-border subscription & notification. See DBA pilot for example of harmonisation.
|For subscribing and notifying on company events / changes there needs to be a specified set of harmonised company event types.
|}

[[Pilot Procedures|Next Chapter: 4. Pilot Procedures]]

DBA 2nd iteration Solution Architecture

2021-09-21T14:18:37Z

Bart.vanbekkum: comments handover WP5 WP3 processed

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

==Solution architecture for DBA authentication and powers validation==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

===General design decisions===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

#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.
#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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
#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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

===Process realisation===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

===Component description===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''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 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).
|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:
*authentication at ''LoA substantial''
*the natural person attributes (at least the mandatory ones) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''
* the legal person attributes (at least the mandatory ones)

In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:

*deny the user access in case of an “authentication failed”-reply.
*grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

*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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

===Functional requirements===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

===Component Deployment===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

===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

===Configuration of harmonised services===
Principles for configuration:

*The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

==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 WP5.
*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 WP3:

*DBA requests WP3 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.

===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 (WP3).
*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.
*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.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.

===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 DE4A WP5. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.

[[File:OOP TS S&N.png|alt=OOP TS DBA Subscription & Notification|none|frame|OOP TS DBA Subscription & Notification]]
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 Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.

=====''Subscription''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Initiate subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
*DE4A connector
|-
|Change subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
|-
|Lookup event provider routing information (DC)
|Inquire Routing Information
|
*IDK
*DNS & SML
*MS SMP
|-
|Send subscription request (DC)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service

*
| eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate subscription request (DP)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery access point:
*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
*IDK
*DNS & SML
*MS SMP
|-
|Exception: Send subscription error message (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Exception: Forward subscription error (DC)
|
|
*Back-office to OOP TS interface
*DE4A connector
|-
|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
|
*Subscription System
*DE4A connector
*IDK
*DNS & SML
*MS SMP
|-
|Send subscription confirmation (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Forward confirmation (DC)
|n/a
|
*Back-office to OOP TS interface
*DE4A connector
|-
|Log subscription information (DC)
|n/a
|eProcedure Back-office Backend
|}
=====''Notification''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Identify cross-border event (DP)
|Cross-border Event Filter
|Cross-border Event Handler
|-
|Check subscriptions (DP)
|Subscription Lookup
|
*Cross-border Event Handler
*Subscription System
|-
|Prepare notification message and subscriber list (DP)
|Notification Message and Subscriber List Preparation
|
*Cross-border Event Handler
*DE4A connector
*Event handler to OOP TS interface
|-
|Exception: Resend past events (DP)
|out of scope
|out of scope
|-
|Resolve service metadata (DP)
|Inquire Routing Information
|
*IDK
*DNS & SML
*MS SMP
|-
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)
|out of scope
|out of scope
|-
|Send event notification (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery Access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate event notification (DC)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery Access point:
*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
|}

===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.
{| class="wikitable"
|'''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:

*collecting relevant data for a subscription request
*keeping track of subscriptions of the DE
*processing subscription confirmations / errors
*determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
*updating logs

|DE
|specific
|Requires new functionality for S&N pattern in each of the DE's.

'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO.

|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

*requesting (changes to) subscriptions
* receiving subscription confirmations / errors
*receiving notifications
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.

As the DBA pilot 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.

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

'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?
|}
<nowiki>*</nowiki>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

===Functional requirements===
The table below presents the requirements that the components involved need to implement.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

#a company
#one or more business events (catalogue & type)
|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.
|
|-
| rowspan="3" |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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|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.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

*translate national events to harmonised events (as defined by the event catalogue)
*filter national events for relevance (i.e. presence in event catalogue)
*query the subscription system for subscribers to a particular event
*construct notification message for each of the subscribers
|
|-
|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.
|-
| rowspan="2" |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.

{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="4" |DE mock
|1
|Requesting a subscription:

* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct subscription request
* show subscription request on web page
* XML output: send request to DE4A connector
|
|-
|2
|Show subscription confirmation on web page.
|
|-
|3
|Show subscription error on web page.
|
|-
|4
|Changing a registered subscription:

* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct change request
* show change request on web page
* XML output: send request to DE4A connector
|
|-
| rowspan="2" |DO mock
|1
|Subscription system - process requests:

* XML input: registration request / change request:
* register a subscription / change a registered subscription
* XML output: confirm registration / send registration error
|
|-
|2
|Event handler - Construct and send a notification:

* user input: company identifier
* user select: harmonised event
* check subscriptions for this company
* show subscriptions on web page
* construct notification(s)
* show notifications XML on web page
* XML output: send notifications
|
|}

===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 WP3:

*design messages for subscription request, subscription confirmation, subscription error and notification.
* analysis and design authorisation controller (out of scope for piloting)

Expectation for WP5:

*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

===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).
{| class="wikitable"
|+
!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)
|}

===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 WP3/WP5 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.
{| class="wikitable"
|'''Component'''
|'''Expected interface'''
|-
|IDK
|IN (from DE4A connector to IDK):

* Member state

* Event catalogue (e.g. DBA = business event)

OUT (from IDK 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 Acess Point):

* Subscription request/registration conformation/notification

OUT (from eDelivery Access Point to DE4A connector):

* ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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''

IN (from DO to DE):

*request ID

*data owner identifier (DO id = participant ID)
*subscriber identifier (DE id = participant ID)
*status (success/fail)

OUT (from DE to DO):

*ACK

''Notification''

IN (from DO to DE4A connector):

*subscriber identifier (DE ID = participant ID)
*data owner identifier (DO id = participant ID)
*notification

#subject identifier (company in question)
#event catalogue
#event
#timestamp event

OUT (from DE4A connector to DR):

*ACK (from DR)
|-
|Subscription system
|IN (from DE4A connector to subscription system) - for subscribing:

* subscription request

OUT:

* subscription confirmation

* subscription error

IN (from cross-border event handler) - for composing the list of notifications:

* subject identifier (company in question)

OUT:

* list of subscribers (DE participant ID's).
|-
|Cross-border Event Handler
|IN

* domestic event

OUT

* array of notifications

|}

==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 WP3:

*DBA requests WP3 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.

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

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

[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]

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.

{| class="wikitable sortable"
|'''Process'''
|'''Application Service'''
|'''Component'''
|-
|Determine required cross-border evidence (DC)
|Cross-border Evidence Matching
|eProcedure Backoffice Back-end:

*Evidence Type Translator

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
|}

===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.
{| class="wikitable"
|'''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:

*translates the required evidence to the canonical evidence to request
*requests the canonical evidence to the MS DE4A connector
*receives the evidence (or error)
*processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).

|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:
*requesting evidence by Lookup

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.
|}
<nowiki>*</nowiki>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

===Functional requirements===
The table below presents the requirements that the components involved need to implement.

{| class="wikitable"
|'''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.

{| class="wikitable"
|'''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.
|
|}

===Component deployment===
*See intermediation pattern.

Expectations for WP3:

*analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)

Expectation for WP5:

*double check to ensure the common components can be re-used from the intermediation pattern without any change.

===Logical interfaces===
The expected logical interfaces remain unchanged.
==Solution architecture for Intermediation Pattern==
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|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.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="2" |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.
|}

==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-31T09:31:57Z

Bart.vanbekkum: /* Component deployment */ typo

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

==Solution architecture for DBA authentication and powers validation==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

===General design decisions===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

#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.
#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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
#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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

===Process realisation===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

===Component description===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''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 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).
|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:
*authentication at ''LoA substantial''
*the natural person attributes (at least the mandatory ones) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''
* the legal person attributes (at least the mandatory ones)

In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:

*deny the user access in case of an “authentication failed”-reply.
*grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

*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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

===Functional requirements===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

===Component Deployment===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

===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

===Configuration of harmonised services===
Principles for configuration:

*The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

==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 WP5.
*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 WP3:

*DBA requests WP3 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.

===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 (WP3).
*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.
*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.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.

===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 DE4A WP5. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.

[[File:OOP TS S&N.png|alt=OOP TS DBA Subscription & Notification|none|frame|OOP TS DBA Subscription & Notification]]
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 Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.

=====''Subscription''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Initiate subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
*DE4A connector
|-
|Change subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
|-
|Lookup event provider routing information (DC)
|Inquire Routing Information
|
*ESL config file
*DNS & SML
*MS SMP
|-
|Send subscription request (DC)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service

*
| eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate subscription request (DP)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery access point:
*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
*ESL config file
*DNS & SML
*MS SMP
|-
|Exception: Send subscription error message (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Exception: Forward subscription error (DC)
|
|
*Back-office to OOP TS interface
*DE4A connector
|-
|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
|
*Subscription System
*DE4A connector
*ESL config file
*DNS & SML
*MS SMP
|-
|Send subscription confirmation (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Forward confirmation (DC)
|n/a
|
*Back-office to OOP TS interface
*DE4A connector
|-
|Log subscription information (DC)
|n/a
|eProcedure Back-office Backend
|}
=====''Notification''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Identify cross-border event (DP)
|Cross-border Event Filter
|Cross-border Event Handler
|-
|Check subscriptions (DP)
|Subscription Lookup
|
*Cross-border Event Handler
*Subscription System
|-
|Prepare notification message and subscriber list (DP)
|Notification Message and Subscriber List Preparation
|
*Cross-border Event Handler
*DE4A connector
*Event handler to OOP TS interface
|-
|Exception: Resend past events (DP)
|out of scope
|out of scope
|-
|Resolve service metadata (DP)
|Inquire Routing Information
|
*ESL config file
*DNS & SML
*MS SMP
|-
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)
|out of scope
|out of scope
|-
|Send event notification (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery Access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate event notification (DC)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery Access point:
*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
|}

===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.
{| class="wikitable"
|'''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:

*collecting relevant data for a subscription request
*keeping track of subscriptions of the DE
*processing subscription confirmations / errors
*determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
*updating logs

|DE
|specific
|Requires new functionality for S&N pattern in each of the DE's.

'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO.

|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

*requesting (changes to) subscriptions
* receiving confirmations / errors
*receiving notifications
Just like the portal to OOP TS interface, 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 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 (MS deployment)
|Needs extension for S&N pattern to facilitate interaction on:
- subscriptions

- notifications
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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.

As the DBA pilot 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.

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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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 (MS deployment)
|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 (MS deployment)
|To be developed

'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?
|}

===Functional requirements===
The table below presents the requirements that the components involved need to implement.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

#a company
#one or more business events (catalogue & type)
|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.
|
|-
| rowspan="3" |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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|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.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

*translate national events to harmonised events (as defined by the event catalogue)
*filter national events for relevance (i.e. presence in event catalogue)
*query the subscription system for subscribers to a particular event
*construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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.
|-
| rowspan="2" |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.

{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="4" |DE mock
|1
|Requesting a subscription:

* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct subscription request
* show subscription request on web page
* XML output: send request to DE4A connector
|
|-
|2
|Show subscription confirmation on web page.
|
|-
|3
|Show subscription error on web page.
|
|-
|4
|Changing a registered subscription:

* user input: subscription identifier from DO
* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct change request
* show change request on web page
* XML output: send request to DE4A connector
|
|-
| rowspan="2" |DO mock
|1
|Subscription system - process requests:

* XML input: registration request / change request:
* register a subscription / change a registered subscription
* XML output: confirm registration / send registration error
|
|-
|2
|Event handler - Construct and send a notification:

* user input: company identifier
* user select: harmonised event
* check subscriptions for this company
* show subscriptions on web page
* construct notification(s)
* show notifications XML on web page
* XML output: send notifications
|
|}

===Component deployment===

*DNS, SML will be reused from iteration 1.
* SMP, eDelivery Access Point will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file 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 WP3:

*design messages for subscription request, subscription confirmation, subscription error and notification.
* analysis and design authorisation controller (out of scope for piloting)

Expectation for WP5:

*extend the DE4A connector for S&N
*extend (the configuration of) the integrated AS4 gateway for S&N
*adapt the Evidence service locator (ESL) configuration file / Issuing Authority Locator (IAL) if required for S&N.
*design and develop the cross-border event handler
*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

===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).
{| class="wikitable"
|+
!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)
|}

===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 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 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.
{| class="wikitable"
|'''Component'''
|'''Expected interface'''
|-
|Evidence service locator (ESL) configuration fileIssuing 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 Acess Point):

- subscription request/registration conformation/notification

OUT (from eDelivery Access Point to DE4A connector):

- ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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

IN (from DO to DE):

*request ID

*data owner identifier (DO id = participant ID)
*subscriber identifier (DE id = participant ID)
*status (success/fail)

OUT (from DE to DO):

*ACK

''Notification''

IN (from DO to DE4A connector):

*subscriber identifier (DE ID = participant ID)
*data owner identifier (DO id = participant ID)
*notification

#subject identifier (company in question)
#event catalogue
#event
#timestamp event

OUT (from DE4A connector to DR):

*ACK (from DR)
|-
|Subscription system
|IN (from DE4A connector to subscription system) - for subscribing:

- subscription request

OUT:

- subscription confirmation

- subscription error

IN (from cross-border event handler) - for composing the list of notifications:

- subject identifier (company in question)

OUT:

- list of subscribers (DE participant ID's).
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- array of notifications

|}

==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 WP3:

*DBA requests WP3 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.

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

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

[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]

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.

{| class="wikitable sortable"
|'''Process'''
|'''Application Service'''
|'''Component'''
|-
|Determine required cross-border evidence (DC)
|Cross-border Evidence Matching
|eProcedure Backoffice Back-end:

*Evidence Type Translator

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
|}

===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.
{| class="wikitable"
|'''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:

*translates the required evidence to the canonical evidence to request
*requests the canonical evidence to the MS DE4A connector
*receives the evidence (or error)
*processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).

|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:
*requesting evidence by Lookup

Just like the portal to OOP TS interface, 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 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 (MS deployment)
|No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change.
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|}

===Functional requirements===
The table below presents the requirements that the components involved need to implement.

{| class="wikitable"
|'''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.
|-
|Portal to OOP TS Interface
|
|no Lookup-specific requirements
|
|-
|DE4A connector
|
|no Lookup-specific requirements
|
|-
|ESL/IAL
|
|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.

{| class="wikitable"
|'''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.
|
|}

===Component deployment===
*See intermediation pattern.

Expectations for WP3:

*analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)

Expectation for WP5:

*double check to ensure the common components can be re-used from the intermediation pattern without any change.

===Logical interfaces===
The expected logical interfaces remain unchanged.
==Solution architecture for Intermediation Pattern==
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|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.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="2" |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.
|}

==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-31T09:31:18Z

Bart.vanbekkum: /* Component deployment */ typo

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

==Solution architecture for DBA authentication and powers validation==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

===General design decisions===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

#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.
#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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
#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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

===Process realisation===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

===Component description===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''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 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).
|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:
*authentication at ''LoA substantial''
*the natural person attributes (at least the mandatory ones) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''
* the legal person attributes (at least the mandatory ones)

In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:

*deny the user access in case of an “authentication failed”-reply.
*grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

*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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

===Functional requirements===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

===Component Deployment===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

===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

===Configuration of harmonised services===
Principles for configuration:

*The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

==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 WP5.
*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 WP3:

*DBA requests WP3 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.

===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 (WP3).
*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.
*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.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.

===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 DE4A WP5. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.

[[File:OOP TS S&N.png|alt=OOP TS DBA Subscription & Notification|none|frame|OOP TS DBA Subscription & Notification]]
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 Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.

=====''Subscription''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Initiate subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
*DE4A connector
|-
|Change subscription (DC)
|Subscription Initiation
|
*eProcedure Back-office Backend
*Back-office to OOP TS interface
|-
|Lookup event provider routing information (DC)
|Inquire Routing Information
|
*ESL config file
*DNS & SML
*MS SMP
|-
|Send subscription request (DC)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service

*
| eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate subscription request (DP)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery access point:
*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
*ESL config file
*DNS & SML
*MS SMP
|-
|Exception: Send subscription error message (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Exception: Forward subscription error (DC)
|
|
*Back-office to OOP TS interface
*DE4A connector
|-
|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
|
*Subscription System
*DE4A connector
*ESL config file
*DNS & SML
*MS SMP
|-
|Send subscription confirmation (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Forward confirmation (DC)
|n/a
|
*Back-office to OOP TS interface
*DE4A connector
|-
|Log subscription information (DC)
|n/a
|eProcedure Back-office Backend
|}
=====''Notification''=====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Identify cross-border event (DP)
|Cross-border Event Filter
|Cross-border Event Handler
|-
|Check subscriptions (DP)
|Subscription Lookup
|
*Cross-border Event Handler
*Subscription System
|-
|Prepare notification message and subscriber list (DP)
|Notification Message and Subscriber List Preparation
|
*Cross-border Event Handler
*DE4A connector
*Event handler to OOP TS interface
|-
|Exception: Resend past events (DP)
|out of scope
|out of scope
|-
|Resolve service metadata (DP)
|Inquire Routing Information
|
*ESL config file
*DNS & SML
*MS SMP
|-
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)
|out of scope
|out of scope
|-
|Send event notification (DP)
|
*Message Encryption
*e-Signature Creation Service
*Data Exchange Service
|eDelivery Access point:
*Trust Service Provisioning
*Data Encryption/Decryption
*Data Exchange
|-
|Validate event notification (DC)
|
*eSignature Validation Service
*Message Decryption
*Authority Check (out of scope)
|eDelivery Access point:
*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
|}

===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.
{| class="wikitable"
|'''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:

*collecting relevant data for a subscription request
*keeping track of subscriptions of the DE
*processing subscription confirmations / errors
*determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
*updating logs

|DE
|specific
|Requires new functionality for S&N pattern in each of the DE's.

'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO.

|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

*requesting (changes to) subscriptions
* receiving confirmations / errors
*receiving notifications
Just like the portal to OOP TS interface, 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 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 (MS deployment)
|Needs extension for S&N pattern to facilitate interaction on:
- subscriptions

- notifications
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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.

As the DBA pilot 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.

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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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 (MS deployment)
|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 (MS deployment)
|To be developed

'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?
|}

===Functional requirements===
The table below presents the requirements that the components involved need to implement.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

#a company
#one or more business events (catalogue & type)
|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.
|
|-
| rowspan="3" |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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|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.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

*translate national events to harmonised events (as defined by the event catalogue)
*filter national events for relevance (i.e. presence in event catalogue)
*query the subscription system for subscribers to a particular event
*construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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.
|-
| rowspan="2" |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.

{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="4" |DE mock
|1
|Requesting a subscription:

* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct subscription request
* show subscription request on web page
* XML output: send request to DE4A connector
|
|-
|2
|Show subscription confirmation on web page.
|
|-
|3
|Show subscription error on web page.
|
|-
|4
|Changing a registered subscription:

* user input: subscription identifier from DO
* user input: company identifier, starting date and time, ending date and time (optionally)
* user select: Data Owner
* construct change request
* show change request on web page
* XML output: send request to DE4A connector
|
|-
| rowspan="2" |DO mock
|1
|Subscription system - process requests:

* XML input: registration request / change request:
* register a subscription / change a registered subscription
* XML output: confirm registration / send registration error
|
|-
|2
|Event handler - Construct and send a notification:

* user input: company identifier
* user select: harmonised event
* check subscriptions for this company
* show subscriptions on web page
* construct notification(s)
* show notifications XML on web page
* XML output: send notifications
|
|}

===Component deployment===

*DNS, SML will be reused from iteration 1.
* SMP, eDelivery Access Point will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file 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 WP3:

*design messages for subscription request, subscription confirmation, subscription error and notification.
* analyse and design authorisation controller (out of scope for piloting)

Expectation for WP5:

*extend the DE4A connector for S&N
*extend (the configuration of) the integrated AS4 gateway for S&N
*adapt the Evidence service locator (ESL) configuration file / Issuing Authority Locator (IAL) if required for S&N.
*design and develop the cross-border event handler
*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

===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).
{| class="wikitable"
|+
!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)
|}

===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 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 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.
{| class="wikitable"
|'''Component'''
|'''Expected interface'''
|-
|Evidence service locator (ESL) configuration fileIssuing 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 Acess Point):

- subscription request/registration conformation/notification

OUT (from eDelivery Access Point to DE4A connector):

- ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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

IN (from DO to DE):

*request ID

*data owner identifier (DO id = participant ID)
*subscriber identifier (DE id = participant ID)
*status (success/fail)

OUT (from DE to DO):

*ACK

''Notification''

IN (from DO to DE4A connector):

*subscriber identifier (DE ID = participant ID)
*data owner identifier (DO id = participant ID)
*notification

#subject identifier (company in question)
#event catalogue
#event
#timestamp event

OUT (from DE4A connector to DR):

*ACK (from DR)
|-
|Subscription system
|IN (from DE4A connector to subscription system) - for subscribing:

- subscription request

OUT:

- subscription confirmation

- subscription error

IN (from cross-border event handler) - for composing the list of notifications:

- subject identifier (company in question)

OUT:

- list of subscribers (DE participant ID's).
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- array of notifications

|}

==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 WP3:

*DBA requests WP3 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.

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

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

[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]

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.

{| class="wikitable sortable"
|'''Process'''
|'''Application Service'''
|'''Component'''
|-
|Determine required cross-border evidence (DC)
|Cross-border Evidence Matching
|eProcedure Backoffice Back-end:

*Evidence Type Translator

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
|}

===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.
{| class="wikitable"
|'''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:

*translates the required evidence to the canonical evidence to request
*requests the canonical evidence to the MS DE4A connector
*receives the evidence (or error)
*processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).

|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:
*requesting evidence by Lookup

Just like the portal to OOP TS interface, 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 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 (MS deployment)
|No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change.
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|}

===Functional requirements===
The table below presents the requirements that the components involved need to implement.

{| class="wikitable"
|'''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.
|-
|Portal to OOP TS Interface
|
|no Lookup-specific requirements
|
|-
|DE4A connector
|
|no Lookup-specific requirements
|
|-
|ESL/IAL
|
|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.

{| class="wikitable"
|'''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.
|
|}

===Component deployment===
*See intermediation pattern.

Expectations for WP3:

*analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)

Expectation for WP5:

*double check to ensure the common components can be re-used from the intermediation pattern without any change.

===Logical interfaces===
The expected logical interfaces remain unchanged.
==Solution architecture for Intermediation Pattern==
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|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.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="2" |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.
|}

==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-26T07:49:57Z

Bart.vanbekkum: /* Solution architecture for Subscription & Notification pattern */

== No 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.

== Solution architecture for DBA authentication and powers validation ==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

=== General design decisions ===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

# 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.
# 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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
# 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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

=== Process realisation ===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

=== Component description ===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''Component'''
|'''Type'''
|'''Short description of its use'''
|'''Changes for 2nd iteration piloting'''
|-
|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) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''
* the legal person attributes (at least the mandatory ones)

In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:

* deny the user access in case of an “authentication failed”-reply.
* grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

* 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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

=== Functional requirements ===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

=== Component Deployment ===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

=== 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

=== Configuration of harmonised services ===
Principles for configuration:

* The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

== 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 WP5.
* 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 WP3:

* DBA requests WP3 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.

=== 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 (WP3).
* 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.
* The DC will subscribe in one Member State at a time.
* The DP will notify one Member State at the time. In case DE's from different Member States have subscribed to business events of a single company, the DP needs to notify each of the Member States individually.
* 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.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.

=== 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 DE4A WP5. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.
[[File:OOP TS S&N.png|alt=OOP TS DBA Subscription & Notification|none|frame|OOP TS DBA Subscription & Notification]]
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 Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.

===== ''Subscription'' =====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Initiate subscription (DC)
|Subscription Initiation
|
* eProcedure Back-office Backend
* Back-office to OOP TS interface
* DE4A connector
|-
|Change subscription (DC)
|Subscription Initiation
|
* eProcedure Back-office Backend
* Back-office to OOP TS interface
|-
|Lookup event provider routing information (DC)
|Inquire Routing Information
|
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Send subscription request (DC)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service

*
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Validate subscription request (DP)
|
* eSignature Validation Service
* Message Decryption
* Authority Check
|eDelivery access point:
* 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

* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Exception: Send subscription error message (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Exception: Forward subscription error (DC)
|
|
* Back-office to OOP TS interface
* DE4A connector
|-
|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
|
* Subscription System
* DE4A connector
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Send subscription confirmation (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Forward confirmation (DC)
|n/a
|
* Back-office to OOP TS interface
* DE4A connector
|-
|Log subscription information (DC)
|n/a
|eProcedure Back-office Backend
|}
===== ''Notification'' =====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Identify cross-border event (DP)
|Cross-border Event Filter
|Cross-border Event Handler
|-
|Check subscriptions (DP)
|Subscription Lookup
|
* Cross-border Event Handler
* Subscription System
|-
|Prepare notification message and subscriber list (DP)
|Notification Message and Subscriber List Preparation
|
* Cross-border Event Handler
* DE4A connector
* Event handler to OOP TS interface
|-
|Exception: Resend past events (DP)
|out of scope
|out of scope
|-
|Resolve service metadata (DP)
|Inquire Routing Information
|
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)
|out of scope
|out of scope
|-
|Send event notification (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery Access gateway:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Validate event notification (DC)
|
* eSignature Validation Service
* Message Decryption
* Authority Check
|eDelivery Access gateway:
* 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
|}

=== 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.
{| class="wikitable"
|'''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:

* collecting relevant data for a subscription request
* keeping track of subscriptions of the DE
* processing subscription confirmations / errors
* determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
* updating logs

|DE
|specific
|Requires new functionality for S&N pattern in each of the DE's.

'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO.

|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

* requesting (changes to) subscriptions
* receiving confirmations / errors
* receiving notifications
Just like the portal to OOP TS interface, 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 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 (MS deployment)
|Needs extension for S&N pattern to facilitate interaction on:
- subscriptions

- notifications
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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.

As the DBA pilot 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.

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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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 (MS deployment)
|The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality.
|-
|Event handler to OOP TS Interface
|Interface for connecting the OOP TS with the Cross-border Event Handler.
'''Ivar: why only for event handler? Not for subscription system'''

'''The interfaces are meant as 'logical level interfaces' to bridge OOP TS standard to (if available) national OOP standard. In this case this is very similar to the cross-border event handler. I suggest to remove this component.'''
|DO, DT
|specific
|Needs to be developed and implemented by the DT.
|-
|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 (MS deployment)
|To be developed

'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?
|-
|Notification front-end
|Application component providing the UI for civil servants to dispatch events and consult logging information for trouble shooting.
|DO
|common (MS deployment)?
|Out of scope for piloting DBA.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

# a company
# one or more business events (catalogue & type)
|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.
|
|-
| rowspan="3" |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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|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.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

* translate national events to harmonised events (as defined by the event catalogue)
* filter national events for relevance (i.e. presence in event catalogue)
* query the subscription system for subscribers to a particular event
* construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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.
|-
| rowspan="2" |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"
|
|}

=== Component deployment ===

* DNS, SML will be reused from iteration 1.
* SMP, eDelivery AS4 gateway will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file 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 WP3:

* design messages for subscription request, subscription confirmation, subscription error and notification.
* analyse en design authorisation controller (out of scope for piloting)

Expectation for WP5:

* extend the DE4A connector for S&N
* extend (the configuration of) the integrated AS4 gateway for S&N
* adapt the Evidence service locator (ESL) configuration file / Issuing Authority Locator (IAL) if required for S&N.
* design and develop the cross-border event handler
* examine possibility for generic components for "subscription system" and S&N back-end functionality of "eProcedure back-office backend"

=== 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).
{| class="wikitable"
|+
!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)
|}

===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 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 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.
{| class="wikitable"
|'''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/registration conformation/notification

OUT (from eDelivery AS4 gateway to DE4A connector):

- ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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

IN (from DO to DE):

* request ID

* data owner identifier (DO id = participant ID)
* subscriber identifier (DE id = participant ID)
* status (success/fail)

OUT (from DE to DO):

* ACK

''Notification''

IN (from DO to DE4A connector):

* subscriber identifier (DE ID = participant ID)
* data owner identifier (DO id = participant ID)
* notification

# subject identifier (company in question)
# event catalogue
# event
# timestamp event

OUT (from DE4A connector to DR):

* ACK (from DR)
|-
|Subscription system
|IN (from DE4A connector to subscription system) - for subscribing:

- subscription request

OUT:

- subscription confirmation

- subscription error

IN (from cross-border event handler) - for composing the list of notifications:

- subject identifier (company in question)

OUT:

- list of subscribers (DE participant ID's).
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- array of notifications

|}

== 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:
* Modify DO/DE Mocks for the Lookup pattern: for testing the new pattern, new versions of the DO- and DE-mocks need to be developed by WP5.
* 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 WP3:

* DBA requests WP3 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.

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

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

'''Harold: Authorization Controller ook uit process realization tabellen verwijderen?'''

[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]

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.

{| class="wikitable sortable"
|'''Process'''
|'''Application Service'''
|'''Component'''
|-
|Determine required cross-border evidence (DC)
|Cross-border Evidence Matching
|eProcedure Backoffice Back-end:

* Evidence Type Translator

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
|}

=== 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.
{| class="wikitable"
|'''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:

* translates the required evidence to the canonical evidence to request
* requests the canonical evidence to the MS DE4A connector
* receives the evidence (or error)
* processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).

|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:
* requesting evidence by Lookup

Just like the portal to OOP TS interface, 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 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 (MS deployment)
|No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change.
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|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 (MS deployment)
|None expected.
|-
|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
|common (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.

{| class="wikitable"
|'''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.
|-
|Portal to OOP TS Interface
|
|no Lookup-specific requirements
|
|-
|DE4A connector
|
|no Lookup-specific requirements
|
|-
|ESL/IAL
|
|no Lookup-specific requirements
|
|-
|SMP
|
|no Lookup-specific requirements
|
|-
|eDelivery AS4 gateway
|
|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
|
|}

=== Component deployment ===
* See intermediation pattern.

Expectations for WP3:

* analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)

Expectation for WP5:

* double check to ensure the common components can be re-used from the intermediation pattern without any change.

=== Logical interfaces ===
The expected logical interfaces remain unchanged.
== Solution architecture for Intermediation Pattern ==
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|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.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="2" |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.
|}

==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-26T07:12:27Z

Bart.vanbekkum: /* Solution architecture for Lookup pattern */

== No 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.

== Solution architecture for DBA authentication and powers validation ==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

=== General design decisions ===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

# 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.
# 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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
# 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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

=== Process realisation ===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

=== Component description ===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''Component'''
|'''Type'''
|'''Short description of its use'''
|'''Changes for 2nd iteration piloting'''
|-
|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) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''
* the legal person attributes (at least the mandatory ones)

In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:

* deny the user access in case of an “authentication failed”-reply.
* grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

* 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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

=== Functional requirements ===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

=== Component Deployment ===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

=== 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

=== Configuration of harmonised services ===
Principles for configuration:

* The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

== 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 WP5.
* 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 WP3:

* DBA requests WP3 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 controler should:
** Establishes 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.
** Established 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.

=== 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 (WP3).
* 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.
* The DC will subscribe in one Member State at a time.
* The DP will notify one Member State at the time. In case DE's from different Member States have subscribed to business events of a single company, the DP needs to notify each of the Member States individually.
* 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.
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.

=== 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 DE4A WP5. The image below depicts the solution for the Subscription & Notification pattern (S&N) with the familiar split in the different roles.
[[File:OOP TS S&N.png|alt=OOP TS DBA Subscription & Notification|none|frame|OOP TS DBA Subscription & Notification]]
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 Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.

===== ''Subscription'' =====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Initiate subscription (DC)
|Subscription Initiation
|
* eProcedure Back-office Backend
* Back-office to OOP TS interface
* DE4A connector
|-
|Change subscription (DC)
|Subscription Initiation
|
* eProcedure Back-office Backend
* Back-office to OOP TS interface
|-
|Lookup event provider routing information (DC)
|Inquire Routing Information
|
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Send subscription request (DC)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service

*
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Validate subscription request (DP)
|
* eSignature Validation Service
* Message Decryption
* Authority Check
|eDelivery access point:
* 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

* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Exception: Send subscription error message (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Exception: Forward subscription error (DC)
|
|
* Back-office to OOP TS interface
* DE4A connector
|-
|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
|
* Subscription System
* DE4A connector
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Send subscription confirmation (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery access point:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Forward confirmation (DC)
|n/a
|
* Back-office to OOP TS interface
* DE4A connector
|-
|Log subscription information (DC)
|n/a
|eProcedure Back-office Backend
|}
===== ''Notification'' =====
{| class="wikitable"
|'''Process'''
|'''Application Service'''
|'''Components'''
|-
|Identify cross-border event (DP)
|Cross-border Event Filter
|Cross-border Event Handler
|-
|Check subscriptions (DP)
|Subscription Lookup
|Cross-border Event Handler
Subscription System
|-
|Prepare notification message and subscriber list (DP)
|Notification Message and Subscriber List Preparation
|
* Cross-border Event Handler
* DE4A connector
* Event handler to OOP TS interface
|-
|Exception: Resend past events (DP)
|out of scope
|out of scope
|-
|Resolve service metadata (DP)
|Inquire Routing Information
|
* Data Service Lookup
* ESL config file
* DNS & SML
* MS SMP
|-
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)
|out of scope
|out of scope
|-
|Send event notification (DP)
|
* Message Encryption
* e-Signature Creation Service
* Data Exchange Service
|eDelivery Access gateway:
* Trust Service Provisioning
* Data Encryption/Decryption
* Data Exchange
|-
|Validate event notification (DC)
|
* eSignature Validation Service
* Message Decryption
* Authority Check
|eDelivery Access gateway:
* 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
|}

=== 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.
{| class="wikitable"
|'''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:

* collecting relevant data for a subscription request
* keeping track of subscriptions of the DE
* processing subscription confirmations / errors
* determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
* updating logs

|DE
|specific
|Requires new functionality for S&N pattern in each of the DE's.

'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO.

|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

* requesting (changes to) subscriptions
* receiving confirmations / errors
* receiving notifications
Just like the portal to OOP TS interface, 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 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 (MS deployment)
|Needs extension for S&N pattern to facilitate interaction on:
- subscriptions

- notifications
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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.

As the DBA pilot 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.

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 (MS deployment)
|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 (MS deployment)
|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
|common (centrally hosted by CEF)
|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 (MS deployment)
|The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality.
|-
|Event handler to OOP TS Interface
|Interface for connecting the OOP TS with the Cross-border Event Handler.
'''Ivar: why only for event handler? Not for subscription system'''

'''The interfaces are meant as 'logical level interfaces' to bridge OOP TS standard to (if available) national OOP standard. In this case this is very similar to the cross-border event handler. I suggest to remove this component.'''
|DO, DT
|specific
|Needs to be developed and implemented by the DT.
|-
|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 (MS deployment)
|To be developed

'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?
|-
|Notification front-end
|Application component providing the UI for civil servants to dispatch events and consult logging information for trouble shooting.
|DO
|common (MS deployment)?
|Out of scope for piloting DBA.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

# a company
# one or more business events (catalogue & type)
|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.
|
|-
| rowspan="3" |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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|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.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

* translate national events to harmonised events (as defined by the event catalogue)
* filter national events for relevance (i.e. presence in event catalogue)
* query the subscription system for subscribers to a particular event
* construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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.
|-
| rowspan="2" |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"
|
|}

=== Component deployment ===

* DNS, SML will be reused from iteration 1.
* SMP, eDelivery AS4 gateway will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file 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 WP3:

* design messages for subscription request, subscription confirmation, subscription error and notification.
* analyse en design authorisation controller (out of scope for piloting)

Expectation for WP5:

* extend the DE4A connector for S&N
* extend (the configuration of) the integrated AS4 gateway for S&N
* adapt the Evidence service locator (ESL) configuration file / Issuing Authority Locator (IAL) if required for S&N.
* design and develop the cross-border event handler
* examine possibility for generic components for "subscription system" and S&N back-end functionality of "eProcedure back-office backend"

=== 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).
{| class="wikitable"
|+
!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)
|}

===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 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 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.
{| class="wikitable"
|'''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/registration conformation/notification

OUT (from eDelivery AS4 gateway to DE4A connector):

- ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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

IN (from DO to DE):

* request ID

* data owner identifier (DO id = participant ID)
* subscriber identifier (DE id = participant ID)
* status (success/fail)

OUT (from DE to DO):

* ACK

''Notification''

IN (from DO to DE4A connector):

* subscriber identifier (DE ID = participant ID)
* data owner identifier (DO id = participant ID)
* notification

# subject identifier (company in question)
# event catalogue
# event
# timestamp event

OUT (from DE4A connector to DR):

* ACK (from DR)
|-
|Subscription system
|IN (from DE4A connector to subscription system) - for subscribing:

- subscription request

OUT:

- subscription confirmation

- subscription error

IN (from cross-border event handler) - for composing the list of notifications:

- subject identifier (company in question)

OUT:

- list of subscribers (DE participant ID's).
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- array of notifications

|}

== 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:
* Modify DO/DE Mocks for the Lookup pattern: for testing the new pattern, new versions of the DO- and DE-mocks need to be developed by WP5.
* 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 WP3:

* DBA requests WP3 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.

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

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

'''Harold: Authorization Controller ook uit process realization tabellen verwijderen?'''

[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]

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.

{| class="wikitable sortable"
|'''Process'''
|'''Application Service'''
|'''Component'''
|-
|Determine required cross-border evidence (DC)
|Cross-border Evidence Matching
|eProcedure Backoffice Back-end:

* Evidence Type Translator

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
|}

=== 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.
{| class="wikitable"
|'''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:

* translates the required evidence to the canonical evidence to request
* requests the canonical evidence to the MS DE4A connector
* receives the evidence (or error)
* processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).

|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:
* requesting evidence by Lookup

Just like the portal to OOP TS interface, 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 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 (MS deployment)
|No changes expected.
Double check that the component as deployed for the intermediation pattern can be used without change.
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|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 (MS deployment)
|None expected.
|-
|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
|common (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.

{| class="wikitable"
|'''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.
|-
|Portal to OOP TS Interface
|
|no Lookup-specific requirements
|
|-
|DE4A connector
|
|no Lookup-specific requirements
|
|-
|ESL/IAL
|
|no Lookup-specific requirements
|
|-
|SMP
|
|no Lookup-specific requirements
|
|-
|eDelivery AS4 gateway
|
|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
|
|}

=== Component deployment ===
* See intermediation pattern.

Expectations for WP3:

* analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)

Expectation for WP5:

* double check to ensure the common components can be re-used from the intermediation pattern without any change.

=== Logical interfaces ===
The expected logical interfaces remain unchanged.
== Solution architecture for Intermediation Pattern ==
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|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.
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="2" |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.
|}

==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-20T09:35:20Z

Bart.vanbekkum: /* Functional requirements */ S&N/LKP

== 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 (intermediation pattern remains unchanged, SEMPER extension will be added)
# the Subscription and notification pattern
# the Lookup pattern (the lookup of evidence, not individual attributes).

The solution architecture of (1) has been specified in chapter [[Solution architecture for DBA authentication and powers validation]] and the solution architectures for (2) and (3) have been included in chapter [[Solution architecture for Subscription & Notification pattern and Lookup pattern]].

== Solution architecture for DBA authentication and powers validation ==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

=== General design decisions ===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

# 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.
# 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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
# 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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

=== Process realisation ===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

=== Component description ===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''Component'''
|'''Type'''
|'''Short description of its use'''
|'''Changes for 2nd iteration piloting'''
|-
|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 apply the following rules for granting access after authentication:

* deny the user access in case of an “authentication failed”-reply.
* grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

* 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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

=== Functional requirements ===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

=== Component Deployment ===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

=== 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

=== Configuration of harmonised services ===
Principles for configuration:

* The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

== Solution architecture for Subscription & Notification pattern and Lookup pattern ==
This section specifies the solution for the two additional patterns that will be piloted by the DBA pilot in the second iteration: the Subscription & Notification pattern and the Lookup pattern.

* Within scope
** Modify DO/DE Mocks for S&N en Lookup patterns: for testing the new patterns, new versions of the DO- and DE-mocks need to be developed by WP5.
** Common component for Cross-border subscriptions and notification (optional for MS to use, i.e. not mandatory).
** Event Notification + Evidence Lookup, 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
** Resend a subscription request in case of an error; the possibility to inspect the logs and manually resend a request is deemed sufficient for piloting.
** Include the Evidence in the notification: in case the DE needs (an updated version of) the evidence, it will use the Lookup pattern.
** 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.

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

=== General Design Decisions ===

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

# exchange of cross-border subscription and notification messages
# performing the lookup of an evidence

* 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 (WP3).
* There will be just one data provider 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.
* The DC will subscribe in one Member State at a time.
* The DP will notify one Member State at the time. In case DE's from different Member States have subscribed to business events of a single company, the DP needs to notify each of the Member States individually.
* The explicit request and the preview functions won't be implemented, in both interaction patterns there is no user involvement. Please note that business event notification is considered an extension to the SDGR.

=== Process realisation ===
The solution for the OOP TS chain consists of 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 with the familiar split in the different roles. It is a consolidated view of the Intermediation pattern, Subscription & Notification pattern (S&N) and Lookup pattern (LKP).

[[File:OOP TS DBA.png|alt=OOP TS DBA|none|frame|OOP TS DBA]]The table below presents the components that implement the application services for the DBA pilot. The process realisation is dealt with per pattern with S&N split in two (subscription and notification) as they are independently triggered. See [[Subscription and Notification Pattern]] and [[Lookup Pattern]] for more details.

The process realisation for the intermediation pattern has been specified in the solution architecture for the first pilot iteration already (not included on this page).

===== ''Subscription'' =====
{| class="wikitable"
|'''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'' =====
{| class="wikitable"
|'''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.
{| class="wikitable sortable"
|'''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 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.
{| class="wikitable"
|'''Component'''
|'''Short description of its use'''
|'''Role'''
|'''Genericness'''
|'''Changes for 2nd iteration piloting'''
|-
|eProcedure Portal Back-end
|The eProcedure back-end handles all eProcedure specific logic.
|DE
|specific
|For the S&N pattern this logic might need to be adapted to include rules for informing the user on subscriptions & possibly notifications.
|-
|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
|None.
This interface is used for the intermediation pattern (subscriptions and notifications will be triggered from the eProcedure backoffice)
|-
|eProcedure Back-office Backend
|This component implements back-end functionality for executing the eProcedure. Examples in the context of S&N:

* collecting relevant data for a subscription request
* keeping track of subscriptions of the DE
* processing subscription confirmations / errors
* determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
* updating logs

|DE
|'''TBD'''
|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 as well.

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.
|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

* requesting subscriptions
* receiving confirmations / errors
* receiving notifications
* requesting evidence by Lookup

Just like the portal to OOP TS interface, 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.
|DE, DR
|specific
|Needs to be developed and implemented for the second iteration.
May be partial re-use of the portal-to-OOP 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 (MS deployment)
|Needs extension for S&N and Lookup patterns to facilitate interaction on:
- subscriptions

- notifications

- evidences (Lookup style).
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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, 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.

See logical interfaces section below
|-
|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 (MS deployment)
|None expected.
|-
|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
|common (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|-
|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 (MS deployment)
|The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality.

Needs to be developed and implemented by the DO.
|-
|Event handler to OOP TS Interface
|Interface for connecting the OOP TS with the Cross-border Event Handler.
|DO, DT
|specific
|Needs to be developed and implemented by the DT.
|-
|Authorization Controller
|''In case of LKP''
Establish which data service / evidence types can be requested by the DE/MS and whether this is allowed under applicable Union or national law without user request and preview. This functionality prevents unauthorised lookup of evidences.

''In case of S&N''

Establishes whether the DE is allowed to subscribe.

Established whether the DP is allowed to send a notification. This prevents unauthorised sending of (fake) notifications. TBD: do we need a common functionality for this or can we leave it up to the DE to check whether the notification comes from the authority to which it subscribed?
|DR, DT
|common
|To be developed.
|-
|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 (MS deployment)
|To be developed
|-
|Notification front-end
|Application component providing the UI for civil servants to dispatch events and consult logging information for trouble shooting.
|DO
|common (MS deployment)?
|Out of scope for piloting DBA.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.

'''TO DO: check alignment of table and PSA 2nd iteration.'''
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

# a company
# one or more business events (catalogue & type)
|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.
|
|-
| rowspan="4" |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 DR should provide a facility for delayed forwarding of notifications to the DE.
|The 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.
|-
|3
|The DT needs to confirm having received the subscription request to the DR.
|
|-
|4
|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.
|-
| rowspan="4" |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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|3
|The subscription system should register:
- data evaluator

- company ID

- business event

- starting date & time

- ending date & time
|
|-
|4
|The subscription system should allow for querying which data evaluators to notify in case of a business event.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

* translate national events to harmonised events (as defined by the event catalogue)
* filter national events for relevance (i.e. presence in event catalogue)
* query the subscription system for subscribers to a particular event
* construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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.
|-
|Authorisation controler
|1
|The authorisation controler blocks any message not sent by one of the piloting partners.
|This simple functionality is sufficient for piloting S&N and Lookup.
|-
|Notification fron-end
|1
|Not supported in DBA pilot.
|
|-
| rowspan="2" |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"
|
|}

=== Component deployment ===

* DNS, SML will be reused from iteration 1.
* SMP, eDelivery AS4 gateway will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file probably needs to change to allow for locating the subscription register.
* The DE4A Connector needs an update.
* Various MS specific interfaces may be needed for (sub)system integration.
* Both DE and DO need to do bookkeeping of subscriptions.
* Both DE and DO need event handling functionality.

=== 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).
{| class="wikitable"
|+
!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)
|}

===Logical interfaces===
The expected logical interfaces are expected to remain largely the same with an expansion for the new patterns.

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.
{| class="wikitable"
|'''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/registration conformation/notification

OUT (from eDelivery AS4 gateway to DE4A connector):

- ACK
|-
|DE4A Connector
|''Subscription''
Initiating or changing subscription

IN (from DE 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

IN (from DO to DE):

* request ID

* data owner identifier (DO id = participant ID)
* subscriber identifier (DE id = participant ID)
* status (success/fail)

OUT (from DE to DO):

* ACK

''Notification''

IN (from DO to DE4A connector):

* subscriber identifier (DE ID = participant ID)
* data owner identifier (DO id = participant ID)
* notification

# subject identifier (company in question)
# catalogue event
# event
# timestamp event

OUT (from DE4A connector to DR):

* ACK (from DR)

''Lookup''

As in iteration 1.
|-
|Authorization Controller
|''lookup''

IN

- DE id = participant ID

- evidence type id

OUT

- yes/no

''S&N''

IN

- data evaluator identifier (DE id = participant ID)

- event catalogue

OUT

- yes/no
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- cross-border event or n/a

'''''Ivar: see this components description and requirements. I expect a array of notifications as output. The event handler should not only translate and filter events against the harmonised catalogue, but also query the subscription system for subscribers and construct notification messages'''''
|-
|...
|
|}
==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

DBA 2nd iteration Solution Architecture

2021-08-19T11:53:28Z

Bart.vanbekkum: /* Configuration of harmonised services */ review of eIDAS part

== 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 (intermediation pattern remains unchanged, SEMPER extension will be added)
# the Subscription and notification pattern
# the Lookup pattern (the lookup of evidence, not individual attributes).

The solution architecture of (1) has been specified in chapter [[Solution architecture for DBA authentication and powers validation]] and the solution architectures for (2) and (3) have been included in chapter [[Solution architecture for Subscription & Notification pattern and Lookup pattern]].

== Solution architecture for DBA authentication and powers validation ==
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.

In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be 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.

=== General design decisions ===
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):

# 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.
# 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 will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.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:
# 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 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.

For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]

=== Process realisation ===
The table below presents the components that implement the application services for the DBA pilot.
{| class="wikitable"
|+table: process realisation
|'''Process'''
|'''Application service'''
|'''Components'''
|-
| rowspan="4" |Request authentication, including powers validation
| rowspan="4" |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)
|-
| rowspan="3" |Provide authentication details, including powers declaration
| rowspan="3" |User authentication
|Specific eIDAS proxy
|-
|eIDAS proxy
|-
|SEMPER extension
|}
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]

=== Component description ===
The table below describes each of the components in this solution architecture.
{| class="wikitable"
|+table: component description
|'''Component'''
|'''Type'''
|'''Short description of its use'''
|'''Changes for 2nd iteration piloting'''
|-
|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 apply the following rules for granting access after authentication:

* deny the user access in case of an “authentication failed”-reply.
* grant the user access in case of an “authentication successful”-reply.

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 apply the following rules for granting access after authentication:

* 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"

'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''
|-
|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.
|}

=== Functional requirements ===

The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement.
{| class="wikitable"
|'''Role'''
|'''Component'''
|'''Requirement'''
|
'''Use in pilot iteration 1'''
|'''Use in pilot iteration 2'''
|-
| rowspan="6" |Data evaluator
| rowspan="6" |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
|-
| rowspan="3" |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
|-
| rowspan="8" |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
|-
| rowspan="6" |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
|}

=== Component Deployment ===
The table below shows the required deployment of common components.
{| class="wikitable"
|+
!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).

=== 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

=== Configuration of harmonised services ===
Principles for configuration:

* The DBA pilot will rely 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 will use 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 "SDGR+" harmonised services catalogue.

Proposal for the harmonised services to express powers cross-border:
{| class="wikitable"
|+
table: harmonised services for cross-border validation of powers
!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
|-
|SDGR+
|1
|Starting of a company or opening a branch in another member state
|-
|SDGR+
|2
|Initial registration of a business activity with the business register
|}
*

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

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

== Solution architecture for Subscription & Notification pattern and Lookup pattern ==
This section specifies the solution for the two additional patterns that will be piloted by the DBA pilot in the second iteration: the Subscription & notification pattern and the Lookup pattern.

* Within scope
** Modify DO/DE Mocks for S&N en Lookup patterns: for testing the new patterns, new versions of the DO- and DE-mocks need to be developed by WP5.
** Common component for Cross-border subscriptions and notification (optional for MS to use, i.e. not mandatory).
** Event Notification + Evidence Lookup, 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
** Resend a subscription request in case of an error: instead the possibility to inspect the logs and manually resend a request is deemed sufficient for piloting.
** Include the Evidence in the notification: in case the DE needs (an updates version of) the evidence, it will use the Lookup pattern.
** Attribute Lookup: this solution architecture support Evidence type lookup requesting the full evidence without user interaction. The option to request individual attributes / API-approach is not supported.

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

=== General Design Decisions ===

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

# exchange of cross-border subscription and notification messages
# performing the lookup of an evidence

* 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 (WP3).
* There will be just one data provider per Member state: the business register, where the subscription will be recorded and where the cross-border events are generated, i.e.is the authentic source of company information. The pilot does not support multiple DO's / notifying authorities in one Member State.
* The DC will subscribe in one Member State at a time.
* The DP will notify one Member State at the time. In case DE's from different Member States have subscribed to business events of a single company, the DP needs to notify each of the Member States individually.
* The explicit request and the preview functions won't be implemented, in both interaction patterns there is no user involvement. Please note that business event notification is considered an extension to the SDGR.

=== Process realisation ===
The solution for the OOP TS chain consists of 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 with the familiar split in the different roles. It is a consolidated view of the Intermediation pattern, Subscription & Notification pattern (S&N) and Lookup pattern (LKP).

[[File:OOP TS DBA.png|alt=OOP TS DBA|none|frame|OOP TS DBA]]The table below presents the components that implement the application services for the DBA pilot. The process realisation is dealt with per pattern with S&N split in two (subscription and notification) as they are independently triggered. See [[Subscription and Notification Pattern]] and [[Lookup Pattern]] for more details.

The process realisation for the intermediation pattern has been specified in the solution architecture for the first pilot iteration already (not included on this page).

===== ''Subscription'' =====
{| class="wikitable"
|'''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'' =====
{| class="wikitable"
|'''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.
{| class="wikitable sortable"
|'''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 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.
{| class="wikitable"
|'''Component'''
|'''Short description of its use'''
|'''Role'''
|'''Genericness'''
|'''Changes for 2nd iteration piloting'''
|-
|eProcedure Portal Back-end
|The eProcedure back-end handles all eProcedure specific logic.
|DE
|specific
|For the S&N pattern this logic might need to be adapted to include rules for informing the user on subscriptions & possibly notifications.
|-
|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
|None.
This interface is used for the intermediation pattern (subscriptions and notifications will be triggered from the eProcedure backoffice)
|-
|eProcedure Back-office Backend
|This component implements back-end functionality for executing the eProcedure. Examples in the context of S&N:

* collecting relevant data for a subscription request
* keeping track of subscriptions of the DE
* processing subscription confirmations / errors
* determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)
* updating logs

|DE
|'''TBD'''
|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 as well.

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.
|-
|Back-office to OOP TS
|Interface for connecting the DE's backoffice with the OOP TS for:

* requesting subscriptions
* receiving confirmations / errors
* receiving notifications
* requesting evidence by Lookup

Just like the portal to OOP TS interface, 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.
|DE, DR
|specific
|Needs to be developed and implemented for the second iteration.
May be partial re-use of the portal-to-OOP 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 (MS deployment)
|Needs extension for S&N and Lookup patterns to facilitate interaction on:
- subscriptions

- notifications

- evidences (Lookup style).
|-
|Evidence service locator (ESL) configuration file Issuing Authority Locator (IAL) TBC
|Configuration file for locating the service to reach out to.
|DR, DT
|common (MS deployment)
|'''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, 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.

See logical interfaces section below
|-
|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 (MS deployment)
|None expected.
|-
|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
|common (MS deployment)
|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
|common (centrally hosted by CEF)
|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.
|-
|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 (MS deployment)
|The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality.

Needs to be developed and implemented by the DO.
|-
|Event handler to OOP TS Interface
|Interface for connecting the OOP TS with the Cross-border Event Handler.
|DO, DT
|specific
|Needs to be developed and implemented by the DT.
|-
|Authorization Controller
|''In case of LKP''
Establish which data service / evidence types can be requested by the DE/MS and whether this is allowed under applicable Union or national law without user request and preview. This functionality prevents unauthorised lookup of evidences.

''In case of S&N''

Establishes whether the DE is allowed to subscribe.

Established whether the DP is allowed to send a notification. This prevents unauthorised sending of (fake) notifications. TBD: do we need a common functionality for this or can we leave it up to the DE to check whether the notification comes from the authority to which it subscribed?
|DR, DT
|common
|To be developed.
|-
|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 (MS deployment)
|To be developed
|-
|Notification front-end
|Application component providing the UI for civil servants to dispatch events and consult logging information for trouble shooting.
|DO
|common (MS deployment)?
|Out of scope for piloting DBA.
|}

=== Functional requirements ===
The table below presents the requirements that the components involved need to implement.

'''TO DO: check alignment of table and PSA 2nd iteration.'''
{| class="wikitable"
|'''Component'''
|'''Nr'''
|'''DBA requirement'''
|'''Comment'''
|-
| rowspan="9" |eProcedure Backoffice Backend
|1
|The DE should be able to subscribe to the combination of:

# a company
# one or more business events (catalogue & type)
|For piloting it is sufficient to skipp 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.
|
|-
| rowspan="4" |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 DR should provide a facility for delayed forwarding of notifications to the DE.
|The 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.
|-
|3
|The DT needs to confirm having received the subscription request to the DR.
|
|-
|4
|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.
|-
| rowspan="4" |Subscription system
|1
|The DO should send a confirmation of (un)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).

As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts.
|-
|3
|The subscription system should register:
- data evaluator

- company ID

- business event

- starting date & time

- ending date & time
|
|-
|4
|Then subscription system should allow for querying which data evaluators to notify in case of a business event.
|
|-
| rowspan="10" |Cross-border Event Handler
|1
|The cross-border event handler should:

* translate national events to harmonised events (as defined by the event catalogue)
* filter national events for relevance (i.e. presence in event catalogue)
* query the subscription system for subscribers to a particular event
* construct notification message for each of the subscribers
|
|-
|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.
|
|-
|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 changes" (without specifying which business event has occurred - if any).
|To cover for data changes that might be relevant for the DE without begin a direct consequence of the occurrence of a harmonised business event, e.g. e-mail address changed.
|-
|Authorisation controler
|1
|The authorisation controler blocks any message not sent by one of the piloting partners.
|This simple functionality is sufficient for piloting S&N and Lookup.
|-
|Notification fron-end
|1
|Not supported in DBA pilot.
|
|-
| rowspan="2" |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 top support the event type "Company registration evidence has changed"
|
|}

=== Component deployment ===

* DNS, SML will be reused from iteration 1.
* SMP, eDelivery AS4 gateway will be reused from iteration 1.
* The Evidence service locator (ESL) configuration file probably needs to change to allow for locating the subscription register.
* The DE4A Connector needs an update.
* Various MS specific interfaces may be needed for (sub)system integration.
* Both DE and DO need to do bookkeeping of subscriptions.
* Both DE and DO need event handling functionality.

=== 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).
{| class="wikitable"
|+
!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)
|}

===Logical interfaces===
The expected logical interfaces are expected to remain largely the same with an expansion for the new patterns.

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.
{| class="wikitable"
|'''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/registration conformation/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.
|-
|Authorization Controller
|''lookup''

IN

- DE id = participant ID

- evidence type id

OUT

- yes/no

''S&N''

IN

- data evaluator identifier (DE id = participant ID)

- event catalogue

OUT

- yes/no
|-
|Cross-border Event Handler
|IN
- domestic event

OUT

- cross-border event or n/a

'''''Ivar: see this components description and requirements. I expect a array of notifications as output. The event handler should not only translate and filter events against the harmonised catalogue, but also query the subscription system for subscribers and construct notification messages'''''
|-
|...
|
|}
==Appendix: archimate component diagrams==

===Solution architecture for DBA authentication and powers validation===

===Solution architecture for Subscription & Notification pattern and Lookup pattern===
TODO merge AC's and tailor to pilot increment 2.

Subscription and Notification Pattern

2021-05-14T10:05:43Z

Bart.vanbekkum:

Is used by [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)]]

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Delimitation to BRIS (DBA specific) ===
As concluded in “DE4A Discussion paper BRIS 20200708 Final.docx” BRIS will not be used in the DBA pilot. This also applies for the subscription and notification pattern. The notifications send resorting under BRIS regulation are out of scope of DE4A. The DE4A pattern has its own subscriptions and notifications that do no relate to BRIS regulation. Note that in some cases this could lead to the situation that a Data Evaluator receives both a BRIS and a DE4A notification for one business event.

Note the BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. Thereby reversing the responsibilities.

== Business Process ==

=== Event Subscription ===

==== Business Process ====
[[File:DE4A D2.5 PSA 0.8 evt.jpg|none|thumb]]

==== Activity Table ====
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|Public Service Procedure
|User
|A procedure of a public service provider leads to the registration of a subject. After this registration events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.

The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.

In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Initiate subscription'''
|DE
|Service
|To initiate the subscription data is collected and the subscription need is formulated:

* subject identifier
* data owner identifier
* subscriber identifier

* event catalogue

* action 'subscribe'
* subscription start and end date

The subscription need is forwarded to the Data Requestor (if applicable).

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|To cancel a subscription data is collected and the cancel subscription need is formulated:
* subject identifier
* data owner identifier
* subscriber identifier
* event catalogue
* action 'cancel subscription'
* subscription end date

The cancel subscription need is forward to the Data Requestor (if applicable).
|-
|'''Lookup event provider routing information'''
|DR
|Service
|The DR uses the data owner identifier to look up routing information on the competent authority that facilitates subscription service.
|-
|'''Inform National Contact point that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.

The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).

|-
|'''Forward (un)subscription error'''
|DR
|Service
|The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator.
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
|-
|'''Forward confirmation'''
|DR
|Service
|The confirmation on the (un)subscription request (received from the DT) is forwarded to the Data Evaluator.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|The request is validated on a technical level: xml validation and check on DE authorisation. If the request validates it is forwarded to the Data Owner.

Technical exceptions are out of scope.
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|The (un)subscription request is evaluated to check if the request can be completed:

* Subscription functional checks: does subject exists, is event catalogue supported.

* Cancel subscription functional checks: does subscription exists.

If the request does not pass the functional checks, the request is rejected and an error message will be send.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content of the error message and send it to the Data Transferor (if applicable).

The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.
|-
|'''Send (un)subscription error message'''
|DT
|Service
|The error message is forwarded to the Data Requestor from who the request was received.
|-
|'''Register (un)subscription'''
|DO
|Service
|The Data Owner creates, changes or ends the subscription according the (un)subscription request.
|-
|'''Confirm (un)subscription'''
|DO
|Service
|The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).

The confirmation message contains: (un)subscription result (success), timestamp of (un)subscription, (un)subscription request reference, original (un)subscription request message.
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|The (un)subscription confirmation is send to the Data Requestor from who the request was received. The (un)subscription confirmation message is added to the log.
|}

==== Design decisions ====

===== Explicit request and preview =====
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:

* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
* The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request

''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.

===== Positioning of subscription registration =====
For the location of the subscription registration certain options can be considered:

* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).

* Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

==== Subscription period ====
Including a subscription period with start and end date has several consequences... todo

''Design decision:'' a subscription period with mandatory start and end dates is included in the subscription.

==== Catalogue of DE4A business events ====
tbd, see table below

==== Subscription register requirements ====

===== Evidence exchange and subscription request =====
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.

* In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is sent.

''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.

There are two main choices for the subscription criteria, subscribe to changes in:

* business events
* evidences

''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.''

==== Business event - evidence mapping ====
Below example for [[Doing Business Abroad Pilot]]. Each pilot (domain) must define their common event list including a clear semantic explanation of each business or life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service.
{| class="wikitable"
|+
!DE4A Business event
!Event includes changes in
!Related evidence type
!Comment
|-
|'''Company info event'''
|EUID, Updated company name/updated address/updated head quarters/changed identifier (EUID)/changed legal form/changed representatives
|Company registration
|Split this event in: address change, name change, ...? And with a status change, notify the specific status?
|-
|'''Annual report event'''
|Annual reports
|Annual report
|What is the event? New annual report available, annual report changed, ...? Split this event?
|-
|'''Directors disqualification event'''
|Disqualifications updated for directors
|Directors disqualification
|
|-
|'''National merger event'''
|Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier
|
|Notifications are only relevant when the transferring company has subscribers.
|-
|'''Cross border merger event'''
|Merger initiated/completed/cancelled, transferrring company identifier, aquaring company identifier
|
|Notifications are relevant when the transferring company has subscribers.
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger.
|}

=== Event Notification ===

==== Business Process ====
[[File:DE4A D2.5 PSA 0.8 not.jpg|none|thumb]]

==== Activity Table ====
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|An event - business event or life event - occurs for the subject and this triggers the notification process.

For the pilot Doing Business abroad the subject is the represented company. Business events impacting the company can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.

NB is this action really in scope of the event notification process?
|-
|'''Identify event'''
|DO
|Service
|The Data Owner determines the event identifier.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
|-
|'''Check subscription'''
|DO
|Service
|The subscription register is queried for subscribers to the subject related to the event:

* No active subscriptions: end of process
* Active subscriptions for the DE4A event catalogue found: continue notification process
* Other active subscriptions found: trigger relevant process(es)
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place.
|-
|'''Resolve service metadata'''
|DT
|Service
|Single notifications messages (one for each subscriber) are created from the list of subscribers and the notification payload. The routing information for each notification message is looked up.
The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional).
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|The event notification is send to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|The Data Requestor performs a technical validation of the event notification and forwards it to the Data Evaluator. A technical exception flow is out of scope of this process description.
|-
|'''Determine event response'''
|DE
|Service
|The notified event is analysed and the appropriate response is determined.

The determination result is logged as a part of the audit trail:

* Subject identifier
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or the registered company or branch is no longer active the cancellation of the subscription is requested. Afterwards this will be analysed to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The notified event doesn't have impact on the procedures of the Data Evaluator and is dismissed. No further actions need to be taken.
|-
|'''Evidence update event triggered'''
|DE
|Service
|The lookup pattern is triggered to request a new, current, copy of the relevant evidence.

The pilot Doing Business Abroad will request the Company Registration Evidence.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|The responsible organisational unit is identified and informed in order to take appropriate action. It depends on the specific process if this action can be performed automated or manually.
|}

==== Design decisions ====

===== Response on event notification =====
Functional responses from Data Evaluator to Data Owner after receiving an event notification, for example to inform that appropriate actions have been taken, are out of scope of the Subscription and Notification pattern.

==== Notifications from Subscriber ====
Notifications from Data Evaluator to Data Owner, for example to inform Data Owner on changes in the branch registration, are out of scope of the Subscription and Notification pattern.

== Process Realisation ==
?All on one Page or do we create sub-pages for Business Process and Process Realisation?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]

Subscription and Notification Pattern

2021-05-12T14:31:52Z

Bart.vanbekkum: Add figure business process Notification

Is used by [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)]]

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Working Hypotheses ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

DBA investigated the situations covered by the DBA and in contrast to what is covered by BRIS. For example: DBA covering more than branches, and more types of companies.

=== Delimitation to BRIS ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

== Business Process ==

=== Event Subscription ===

==== Business Process ====
[[File:DE4A D2.5 PSA 0.8 evt.jpg|none|thumb]]

==== Activity Table ====
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|Public Service Procedure
|User
|A procedure of a public service provider leads to the registration of a subject. After this registration events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.

The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.

In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Initiate subscription'''
|DE
|Service
|To initiate the subscription data is collected and the subscription need is formulated:

* subject identifier
* data owner identifier
* subscriber identifier

* event catalogue

* action 'subscribe'
* subscription start and end date

The subscription need is forwarded to the Data Requestor (if applicable).

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|To cancel a subscription data is collected and the cancel subscription need is formulated:
* subject identifier
* data owner identifier
* subscriber identifier
* event catalogue
* action 'cancel subscription'
* subscription end date

The cancel subscription need is forward to the Data Requestor (if applicable).
|-
|'''Lookup event provider routing information'''
|DR
|Service
|The DR uses the data owner identifier to look up routing information on the competent authority that facilitates subscription service.
|-
|'''Inform National Contact point that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.

The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).

|-
|'''Forward (un)subscription error'''
|DR
|Service
|The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator.
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
|-
|'''Forward confirmation'''
|DR
|Service
|The confirmation on the (un)subscription request (received from the DT) is forwarded to the Data Evaluator.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|The request is validated on a technical level: xml validation and check on DE authorisation. If the request validates it is forwarded to the Data Owner.

Technical exceptions are out of scope.
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|The (un)subscription request is evaluated to check if the request can be completed:

* Subscription functional checks: does subject exists, is event catalogue supported.

* Cancel subscription functional checks: does subscription exists.

If the request does not pass the functional checks, the request is rejected and an error message will be send.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content of the error message and send it to the Data Transferor (if applicable).

The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.
|-
|'''Send (un)subscription error message'''
|DT
|Service
|The error message is forwarded to the Data Requestor from who the request was received.
|-
|'''Register (un)subscription'''
|DO
|Service
|The Data Owner creates, changes or ends the subscription according the (un)subscription request.
|-
|'''Confirm (un)subscription'''
|DO
|Service
|The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).

The confirmation message contains: (un)subscription result (success), timestamp of (un)subscription, (un)subscription request reference, original (un)subscription request message.
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|The (un)subscription confirmation is send to the Data Requestor from who the request was received. The (un)subscription confirmation message is added to the log.
|}

==== Design decisions ====

===== Explicit request and preview =====
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:

* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
* The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request

''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.

===== Positioning of subscription registration =====
For the location of the subscription registration certain options can be considered:

* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).

* Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

==== Subscription period ====
Including a subscription period with start and end date has several consequences... todo

''Design decision:'' a subscription period with mandatory start and end dates is included in the subscription.

==== Catalogue of DE4A business events ====
tbd

==== Subscription register requirements ====

===== Evidence exchange and subscription request =====
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.

* In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is sent.

''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.

There are two main choices for the subscrition criteria, subscribe to changes in:

* business events
* evidences

''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.''

==== Business event - evidence mapping ====
Below example for [[Doing Business Abroad Pilot]]. Each pilot (domain) must define tehir common event list includign a clear semantic explanation of each business of life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service/
{| class="wikitable"
|+
!DE4A Business event
!Event includes changes in
!Related evidence type
!Comment
|-
|'''Company info event'''
|EUID, Updated company name/updated address/updated head quarters/changed identifier (EUID)/changed legal form/changed representatives
|Company registration
|
|-
|'''Annual report event'''
|Annual reports
|Annual report
|
|-
|'''Directors disqulification event'''
|Disqualifications updated for directors
|Directors disqulification
|
|-
|'''National merger event'''
|Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier
|
|Notifications are only relevant when the transferring company has subscribers.
|-
|'''Cross border merger event'''
|Merger initiated/completed/cancelled, transferrring company identifier, aquring company identifier
|
|Notifications are relevant when the transferring company has subscribers.
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger.
|}

=== Event Notification ===

==== Business Process ====
[[File:DE4A D2.5 PSA 0.8 not.jpg|none|thumb]]

==== Activity Table ====
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|An event - business event or life event - occurs for the subject and this triggers the notification process.

For the pilot Doing Business abroad the subject is the represented company. Business events impacting the company can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.

NB is this action really in scope of the event notification process?
|-
|'''Identify event'''
|DO
|Service
|The DO determines the DE4A Business event name.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
|-
|'''Check subscription'''
|DO
|Service
|The subscription register is queried for subscribers to the subject related to the event:

* No active subscriptions: end of process
* Active subscriptions for the DE4A event catalogue found: continue notification process
* Other active subscriptions found: trigger relevant process(es)
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place.
|-
|'''Resolve service metadata'''
|DT
|Service
|Single notifications messages (one for each subscriber) are created from the list of subscribers and the notification payload. The routing information for each notification message is looked up.
The messages contain: subject identifier, secondary subject identifier (in case the identifier changed), subscriber identification, event identification, event timestamp, subscription reference (optional).
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|The event notification is send to the Data Requestor, a technical acknowledgement that the notification has been received by the DR is received. The audit log is updated with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|The Data Requestor performs a technical validation of the event notification and forwards it to the Data Evaluator. A technical exception flow is out of scope of this process description.
|-
|'''Determine event response'''
|DE
|Service
|The notified event is analysed and the necessary response is determined.

Note that every determination result is logged as a part of the audit trail or for internal reasons:

* Subject identifier
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or is no longer active the cancellation of the subscription is requested. Afterwards this will have to be analysed to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The notified event is not relevant for the procedures of the Data Evaluator and is dismissed. No further actions need to be taken.
|-
|'''Evidence update event triggered'''
|DE
|Service
|The lookup pattern is triggered to request a new copy of the relevant evidence.

The pilot Doing Business Abroad will request the Company Registration Evidence.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|The responsible organisational unit is identified and informed in order to take appropriate action. It depends on the specific process if this action can be performed automated or manually.
|}

Note:

* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.

== Process Realization ==
?All on one Page or do we create sub-pages for Business Process and Process Realization?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]

Use Case "Doing Business in Another Member State" (DBA UC2)

2021-05-12T14:17:09Z

Bart.vanbekkum: Added DBA specific message notification

The Use Case "Doing Business in Another Member State" of the [[DBA|Doing Business Abroad Pilot]] (DBA UC2) uses the [[Subscription and Notification Pattern]].

This use case focusses at assessing the consequence for active eServices in case of a business event, e.g. company goes bankrupt, company stops it’s activities, company merges, etc. The data consumer may subscribe to notifications on selected business events. In case such an event occurs, the data provider notifies the data consumer. The data consumer needs to assess the relevance of the notification. It can then for example request the updated data from the data provider or decide it doesn’t need any additional data. Furthermore, the data consumer may intervene in an active eService (e.g. stop periodical grants or impose a tax obligation). The data consumer may also use the notifications as input to a general fraud prevention and protection procedure.

==== Message ‘Subscription request’ ====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''M/O'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|O
|RO/AT/90000471
|-
|Requested action
|Indicates whether a subscription or the cancellation of a subscription is requested by the sender: ‘subscribe’ or ‘unsubscribe’
|M
|subscribe
|-
|Participant ID
|The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications)
|O
|SE000000013
|-
|Business event type
|The business event to subscribe to. If omitted, subscribe to all business events
|O
|
|-
|Legal person identifier
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
|M
|
|-
|Subscription period
|The period for which the subscription is valid. If omitted subscription is valid until a unsubcribe request.
|O
|
|-
|TBD: event catalogue
|The domain of events the subscription is
|
|
|-
|TBD: subscription period
|The date of beginning and ending (optional) of the subscription
|
|
|}

==== Message ‘Subscription confirmation’ ====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Subscription timestamp
|
|
|-
|Subscription result
|Subscription successful ; subscription cancellation successful
|
|-
|Subscription request reference
|
|
|-
|Subscription reference
|Local identifier of the subscription. Not needed but can be useful in exception flows
|
|}

==== Message ‘Subscription error’ ====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Request type
|Subscribe / unsubscribe
|
|-
|Error timestamp
|
|
|-
|Subscriber identification
|
|
|-
|Error message
|Subscribe: company unknown, (participant not authorized)
Unsubscribe: company unknown, company not active, subscription unknown, subscription not active

>move this text to subpage DBA
|
|-
|Subscription request reference
|
|
|}

==== Message ‘Business event notification’ ====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''M/O'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|O
|
|-
|Business event identification
|The identification of the business event (list of value: OOP TS business event catalogue)
|O
|
|-
|Business event timestamp
|Date and time of business event
|M
|2021-05-01 15:01:27
|-
|Subscription reference
|Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows
|O
|
|-
|Legal person identifier
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
|M
|SEBOLREG.5560802
|-
|Second legal person identifier
|Identification of a second company or a second EUID, used for example if the original EUID is changed
|O
|SEBOLREG.5594521
|-
|Business event type
|The business event that triggered the notification, see Event - evidence mapping table above.
|M
|National merger
|-
|Business sub event type
|The subtype of the business event.
|O
|Initiated
|}

File:DE4A D2.5 PSA 0.8 not.jpg

2021-05-12T13:24:23Z

Bart.vanbekkum:

Figure Event Notification Business proves v08

Use Case "Doing Business in Another Member State" (DBA UC2)

2021-05-12T13:21:46Z

Bart.vanbekkum: Added messages

Subscription and Notification Pattern

2021-05-12T13:16:50Z

Bart.vanbekkum: Add figure Event Not and moved DBA specific text to DBA Use case page

Is used by [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)]]

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Working Hypotheses ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

DBA investigated the situations covered by the DBA and in contrast to what is covered by BRIS. For example: DBA covering more than branches, and more types of companies.

=== Delimitation to BRIS ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

== Business Process ==

=== Event Subscription ===

==== Business Process ====
[[File:DE4A D2.5 PSA 0.8 evt.jpg|none|thumb]]

==== Activity Table ====
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|Public Service Procedure
|User
|A procedure of a public service provider leads to the registration of a subject. After this registration events can occur to the subject that could have impact on the service delivery to this subject. In order to be informed on these events, the public service provider can subscribe to the life-events or business-events of the subject.

The subscription process can also be triggered for technical reasons: for instance to resend failed subscription requests.

In the pilot Doing Business Abroad the subject is the represented company itself or a new branch of the represented company (the parent-company of the branch) and Data Evaluators subscribe to be notified on the business events of the represented company.

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Initiate subscription'''
|DE
|Service
|To initiate the subscription data is collected and the subscription need is formulated:

* subject identifier
* data owner identifier
* subscriber identifier

* event catalogue

* action 'subscribe'
* subscription start and end date

The subscription need is forwarded to the Data Requestor (if applicable).

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: public service delivery can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription.

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|To cancel a subscription data is collected and the cancel subscription need is formulated:
* subject identifier
* data owner identifier
* subscriber identifier
* event catalogue
* action 'cancel subscription'
* subscription end date

The cancel subscription need is forward to the Data Requestor (if applicable).
|-
|'''Lookup event provider routing information'''
|DR
|Service
|The DR uses the data owner identifier to look up routing information on the competent authority that facilitates subscription service.
|-
|'''Inform National Contact point that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|The request to subscribe or unsubscribe is send to the participant facilitating the subscription service using the previously retrieved routing information.

The subscription / cancel subscription request contains: the participant id of the subscriber, the subject identifier, the event catalogue, the period of subscription and the requested action (subscribe / cancel subscription).

|-
|'''Forward (un)subscription error'''
|DR
|Service
|The (un)subscription error message received from Data Transferor is forwarded to the Data Evaluator.
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|The received error message is analysed and appropriate actions are taken. This exception flow is not further detailed in this design.
|-
|'''Forward confirmation'''
|DR
|Service
|The confirmation on the (un)subscription request (received from the DT) is forwarded to the Data Evaluator.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|The request is validated on a technical level: xml validation and check on DE authorisation. If the request validates it is forwarded to the Data Owner.

Technical exceptions are out of scope.
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|The (un)subscription request is evaluated to check if the request can be completed:

* Subscription functional checks: does subject exists, is event catalogue supported.

* Cancel subscription functional checks: does subscription exists.

If the request does not pass the functional checks, the request is rejected and an error message will be send.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content of the error message and send it to the Data Transferor (if applicable).

The (un)subscription error message contains: participant id of subscriber, subject identifier, requested action, reference to the request message, full request message and the errorcode.
|-
|'''Send (un)subscription error message'''
|DT
|Service
|The error message is forwarded to the Data Requestor from who the request was received.
|-
|'''Register (un)subscription'''
|DO
|Service
|The Data Owner creates, changes or ends the subscription according the (un)subscription request.
|-
|'''Confirm (un)subscription'''
|DO
|Service
|The confirmation of the (un)subscription is created and send to the Data Transferor (if applicable).

The confirmation message contains: (un)subscription result (success), timestamp of (un)subscription, (un)subscription request reference, original (un)subscription request message.
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|The (un)subscription confirmation is send to the Data Requestor from who the request was received. The (un)subscription confirmation message is added to the log.
|}

==== Design decisions ====

===== Explicit request and preview =====
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:

* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
* The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request

''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.

===== Positioning of subscription registration =====
For the location of the subscription registration certain options can be considered:

* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).

* Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

==== Subscription period ====
Including a subscription period with start and end date has several consequences... todo

''Design decision:'' a subscription period with mandatory start and end dates is included in the subscription.

==== Catalogue of DE4A business events ====
tbd

==== Subscription register requirements ====

===== Evidence exchange and subscription request =====
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.

* In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is sent.

''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.

There are two main choices for the subscrition criteria, subscribe to changes in:

* business events
* evidences

''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.''

==== Business event - evidence mapping ====
Below example for [[Doing Business Abroad Pilot]]. Each pilot (domain) must define tehir common event list includign a clear semantic explanation of each business of life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service/
{| class="wikitable"
|+
!DE4A Business event
!Event includes changes in
!Related evidence type
!Comment
|-
|'''Company info event'''
|EUID, Updated company name/updated address/updated head quarters/changed identifier (EUID)/changed legal form/changed representatives
|Company registration
|
|-
|'''Annual report event'''
|Annual reports
|Annual report
|
|-
|'''Directors disqulification event'''
|Disqualifications updated for directors
|Directors disqulification
|
|-
|'''National merger event'''
|Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier
|
|Notifications are only relevant when the transferring company has subscribers.
|-
|'''Cross border merger event'''
|Merger initiated/completed/cancelled, transferrring company identifier, aquring company identifier
|
|Notifications are relevant when the transferring company has subscribers.
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger.
|}

=== Event Notification ===
Business Process (picture)
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|An event regarding the company triggers the notification process. This event can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.
|-
|'''Identify event'''
|DO
|Service
|The DO determines the DE4A Business event name.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
|-
|'''Check subscription'''
|DO
|Service
|Check the subscription register for subscribers to the company that is the subject of the business event:

* No active subscriptions: end of process
* Active subscriptions found: continue notification process
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place.
|-
|'''Resolve service metadata'''
|DT
|Service
|Move from a list of subscribers to single notifications (one for each subscriber) and lookup the routing information for each notification.
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|Send notification, receive the acknowledgement that the notification has been received by the DR and update the audit log with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|DR performs a technical validation of the event notification and forward it to the DE. A technical exception flow is out of scope of this process description.

Log received message as part of audit trail?
|-
|'''Determine event response'''
|DE
|Service
|Check the notified business event and determine the action to be taken.

Note that every determination result is logged as a part of the audit trail or for internal reasons:

* Company identifier
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or is no longer active. Afterwards this will have to be analysed this to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The business event is not relevant for the DE and is dismissed. No further actions need to be taken.
|-
|'''Evidence update event triggered'''
|DE
|Service
|The lookup pattern is triggered to request a new copy of the Company Registration Evidence.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|Notify responsible party or organizational unit (that then contacts the company if needed).

Depends on process, case by case, if this can be automated or manually.
|}

Note:

* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.

==== Messages ====

===== Message ‘Business event notification’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''M/O'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|O
|
|-
|Business event identification
|The identification of the business event (list of value: OOP TS business event catalogue)
|O
|
|-
|Business event timestamp
|Date and time of business event
|M
|2021-05-01 15:01:27
|-
|Subscription reference
|Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows
|O
|
|-
|Legal person identifier
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
|M
|SEBOLREG.5560802
|-
|Second legal person identifier
|Identification of a second company or a second EUID, used for example if the original EUID is changed
|O
|SEBOLREG.5594521
|-
|Business event type
|The business event that triggered the notification, see Event - evidence mapping table above.
|M
|National merger
|-
|Business sub event type
|The subtype of the business event.
|O
|Initiated
|}

== Process Realization ==
?All on one Page or do we create sub-pages for Business Process and Process Realization?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]

File:DE4A D2.5 PSA 0.8 evt.jpg

2021-05-12T11:27:05Z

Bart.vanbekkum:

Figure of the Event Subscription Business Process

Subscription and Notification Pattern

2021-05-11T12:38:23Z

Bart.vanbekkum: Align with new schemeversion on business events

Is used by [[Doing Business Abroad Pilot]] in [[Use Case "Doing Business in Another Member State" (DBA UC2)]]

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Working Hypotheses ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

DBA investigated the situations covered by the DBA and in contrast to what is covered by BRIS. For example: DBA covering more than branches, and more types of companies.

=== Delimitation to BRIS ===
BRIS proposed change in the technical working group: Subscription will be replaced by a push notification through registering international branches in the registry of the mother company. That is reversing the responsibilities.

== Business Process ==

=== Event Subscription ===

Business Process (picture)

Activity Table
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|Public Service Procedure
|User
|The Procedure leads at the side of the data-evaluator to either the registration of the represented company or the registration of a branch of the represented company (the parent-company of the branch).

A successful registration of the company or the branch of the company leads to a subscription to business events of the represented company. This is needed to assess impact of these business events on service delivery to the company or the branch.

The subscription process can also be triggered for technical reasons: for instance to resend subscription requests because an error occurred at DO-side.

|-
|'''Initiate subscription'''
|DE
|Service
|Initiate subscription:

* Collect data and formulate subscription need:
** subject identifier
** all events of a common event catalogue
** type of action: subscribe
** period of subscription
* Forward to Data Requestor (if applicable)

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: the delivery of an public service can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription?

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|Cancel subscription:

* Collect data and formulate cancel subscription need:
** company identifier
** all events of subset/type of events (specific event catalogue)? tbd
** type of action: cancel subscription
** specific end-date of the subscription? tbd
* Forward to Data requestor (if applicable)
|-
|'''Lookup event provider routing information'''
|DR
|Service
|Lookup information on competent authority that facilitates subscription service (dynamic lookup, metadata tbd)
|-
|'''Inform National Contact point that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|Send the request to subscribe or unsubscribe to the DT.

Subscription / cancel subscription request contains: participant id of subscriber, subject identifier, set of common events, period of subscription, action (subscribe/cancel subscription).

|-
|'''Forward (un)subscription error'''
|DR
|Service
|Forward (un)subscription error message received from DT to DE.
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|Analyse error and take appropriate actions (error could be on side of DE of DO) (exception so no need to model this in detail)
|-
|'''Forward confirmation'''
|DR
|Service
|Forward the confirmation on the (un)subscription request (received from the DT) to the DE.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|Technical validation (xml validation and check on DE authorisation).including forwarding to data owner. Technical exception out of scope
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|Functional check of request to subscribe: does company exists, are type of events/subscription supported.

Functional check of request to unsubscribe: does subscription exists.

If the request does not pass the functional check, the request is rejected.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content (mainly the link to the request and the error message) and send it to DT
|-
|'''Send (un)subscription error message'''
|DT
|Service
|Forward to DR.

Message contains: participant id of subscriber, subject identifier, request type, reference to the request message, full request message, error
|-
|'''Register (un)subscription'''
|DO
|Service
|Data owner creates/ends the DE’s subscription on the company’s events.

Remarks:

* If messages resemble BRIS messages that would avoid extra work to be done; because this mechanism is in already in place
* Harmonised set of business events needed.
|-
|'''Confirm (un)subscription'''
|DO
|Service
|Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable)
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|Send confirmation to DR

Log confirmation
|}

==== Subscription messages ====

===== Message ‘Subscription request’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''M/O'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|O
|RO/AT/90000471
|-
|Requested action
|Indicates whether a subscription or the cancellation of a subscription is requested by the sender: ‘subscribe’ or ‘unsubscribe’
|M
|subscribe
|-
|Participant ID
|The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications)
|O
|SE000000013
|-
|Business event type
|The business event to subscribe to. If omitted, subscribe to all business events
|O
|
|-
|Legal person identifier
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
|M
|
|-
|Subscription period
|The period for which the subscription is valid. If omitted subscription is valid until a unsubcribe request.
|O
|
|-
|TBD: event catalogue
|The domain of events the subscription is
|
|
|-
|TBD: subscription period
|The date of beginning and ending (optional) of the subscription
|
|
|}

===== Message ‘Subscription confirmation’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Subscription timestamp
|
|
|-
|Subscription result
|Subscription successful ; subscription cancellation successful
|
|-
|Subscription request reference
|
|
|-
|Subscription reference
|Local identifier of the subscription. Not needed but can be useful in exception flows
|
|}

===== Message ‘Subscription error’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Request type
|Subscribe / unsubscribe
|
|-
|Error timestamp
|
|
|-
|Subscriber identification
|
|
|-
|Error message
|Subscribe: company unknown, (participant not authorized)

Unsubscribe: company unknown, company not active, subscription unknown, subscription not active

>move this text to subpage DBA
|
|-
|Subscription request reference
|
|
|}

==== Design decisions ====

===== Explicit request and preview =====
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:

* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
* The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request

''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.

===== Positioning of subscription registration =====
For the location of the subscription registration certain options can be considered:

* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).

* Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

===== Evidence exchange and subscription request =====
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.

* In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is sent.

''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.

There are two main choices for the subscrition criteria, subscribe to changes in:

* business events
* evidences

''Design decision: not all business events are related to an evidence, subscriptions must therefore be made to business events to cover all notifications to be sent, see table below.''

==== Business event - evidence mapping ====
Below example for [[Doing Business Abroad Pilot]]. Each pilot (domain) must define tehir common event list includign a clear semantic explanation of each business of life event in order for the Data Evaluator to be able to interpret the event correctly and define an appropriate course of action, e.g. request an updated evidence or discontinue the public service/
{| class="wikitable"
|+
!DE4A Business event
!Event includes changes in
!Related evidence type
!Comment
|-
|'''Company info event'''
|EUID, Updated company name/updated address/updated head quarters/changed identifier (EUID)/changed legal form/changed representatives
|Company registration
|
|-
|'''Annual report event'''
|Annual reports
|Annual report
|
|-
|'''Directors disqulification event'''
|Disqualifications updated for directors
|Directors disqulification
|
|-
|'''National merger event'''
|Merger initiated/completed/cancelled, transferring company identifier, aquring company identifier
|
|Notifications are only relevant when the transferring company has subscribers.
|-
|'''Cross border merger event'''
|Merger initiated/completed/cancelled, transferrring company identifier, aquring company identifier
|
|Notifications are relevant when the transferring company has subscribers.
This event is also relevant without a subscription. The business register of a company involved in a merger wants notifications even if there is no prior subscription to the foreign company in the cross border merger.
|}

=== Event Notification ===
Business Process (picture)
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|An event regarding the company triggers the notification process. This event can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.
|-
|'''Identify event'''
|DO
|Service
|The DO determines the DE4A Business event name.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
|-
|'''Check subscription'''
|DO
|Service
|Check the subscription register for subscribers to the company that is the subject of the business event:

* No active subscriptions: end of process
* Active subscriptions found: continue notification process
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place.
|-
|'''Resolve service metadata'''
|DT
|Service
|Move from a list of subscribers to single notifications (one for each subscriber) and lookup the routing information for each notification.
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|Send notification, receive the acknowledgement that the notification has been received by the DR and update the audit log with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|DR performs a technical validation of the event notification and forward it to the DE. A technical exception flow is out of scope of this process description.

Log received message as part of audit trail?
|-
|'''Determine event response'''
|DE
|Service
|Check the notified business event and determine the action to be taken.

Note that every determination result is logged as a part of the audit trail or for internal reasons:

* Company identifier
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or is no longer active. Afterwards this will have to be analysed this to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The business event is not relevant for the DE and is dismissed. No further actions need to be taken.
|-
|'''Evidence update event triggered'''
|DE
|Service
|The lookup pattern is triggered to request a new copy of the Company Registration Evidence.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|Notify responsible party or organizational unit (that then contacts the company if needed).

Depends on process, case by case, if this can be automated or manually.
|}

Note:

* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.

==== Messages ====

===== Message ‘Business event notification’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''M/O'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|O
|
|-
|Business event identification
|The identification of the business event (list of value: OOP TS business event catalogue)
|O
|
|-
|Business event timestamp
|Date and time of business event
|M
|2021-05-01 15:01:27
|-
|Subscription reference
|Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows
|O
|
|-
|Legal person identifier
|Identification of the company following the standard for EUID, <country code><business register code>.<company identifier>_<optional check character>. EUID is used for all companies registered in a European business register.
|M
|SEBOLREG.5560802
|-
|Second legal person identifier
|Identification of a second company or a second EUID, used for example if the original EUID is changed
|O
|SEBOLREG.5594521
|-
|Business event type
|The business event that triggered the notification, see Event - evidence mapping table above.
|M
|National merger
|-
|Business sub event type
|The subtype of the business event.
|O
|Initiated
|}

== Process Realization ==
?All on one Page or do we create sub-pages for Business Process and Process Realization?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]

Subscription and Notification Pattern

2021-05-10T13:26:59Z

Bart.vanbekkum:

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Working Hypotheses ===

== Business Process ==

=== Event Subscription ===

Business Process (picture)

Activity Table
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|eProcedure
|User
|The eProcedure leads at the side of the data-evaluator to either the registration of the represented company or the registration of a branch of the represented company (the parent-company of the branch).

A successful registration of the company or the branch of the company leads to a subscription to business events of the represented company. This is needed to assess impact of these business events on service delivery to the company or the branch.

The subscription process can also be triggered for technical reasons: for instance to resend subscription requests because an error occurred at DO-side.

|-
|'''Initiate subscription'''
|DE
|Service
|Initiate subscription:

* Collect data and formulate subscription need:
** company identifier
** all events of subset/type of events (specific event catalogue)? tbd
** type of action: subscribe
** period of subscription? tbd
* Forward to Data requestor (if applicable)

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: the delivery of an public service can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription?

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|Cancel subscription:

* Collect data and formulate cancel subscription need:
** company identifier
** all events of subset/type of events (specific event catalogue)? tbd
** type of action: cancel subscription
** specific end-date of the subscription? tbd
* Forward to Data requestor (if applicable)
|-
|'''Lookup event provider routing information'''
|DR
|Service
|Lookup information on competent authority that facilitates subscription service (metadata tbd)

(should data requestor resolve participant id dynamically? Not needed, participant id is stable enough)
|-
|'''Inform National Coordinator that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|Send the request to subscribe or unsubscribe to the DT.
|-
|'''Forward (un)subscription error'''
|DR
|Service
|Forward (un)subscription error message received from DT to DE
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|Analyse error and take appropriate actions (error could be on side of DE of DO) (exception so no need to model this in detail)
|-
|'''Forward confirmation'''
|DR
|Service
|Forward the confirmation on the (un)subscription request (received from the DT) to the DE.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|Technical validation including forwarding to data owner. Technical exception out of scope
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|Functional check of request to subscribe: does company exists, are type of events/subscription supported, is DE authorized.

Functional check of request to unsubscribe: does subscription exists.

If the request does not pass the functional check, the request is rejected.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content (mainly the link to the request and the error message) and send it to DT
|-
|'''Send (un)subscription error message'''
|DT
|Service
|Forward to DR
|-
|'''Register (un)subscription'''
|DO
|Service
|Data owner creates/ends the DE’s subscription on the company’s events.

Remarks:

* If messages resemble BRIS messages that would avoid extra work to be done; because this mechanism is in already in place
* Harmonised set of business events possibly needed.
* Register on evidence type: tbd
|-
|'''Confirm (un)subscription'''
|DO
|Service
|Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable)
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|Send confirmation to DR

Log confirmation
|}

* A / M = Automated or Manual

==== Messages ====

===== Message ‘Subscription request’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|RO/AT/90000471
|-
|Requested action
|Indicates whether a subscription or the cancellation of a subscription is requested by the sender: ‘subscribe’ or ‘unsubscribe’
|subscribe
|-
|Participant ID
|The OOP TS participant identifier that identifies the organisation that is the subscriber (and thus will receive business event notifications)
|SE000000013
|-
|
|
|
|-
|TBD: event catalogue
|The domain of events the subscription is
|
|-
|TBD: subscription period
|The date of beginning and ending (optional) of the subscription
|
|}

===== Message ‘Subscription confirmation’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Subscription timestamp
|
|
|-
|Subscription result
|Subscription successful ; subscription cancellation successful
|
|-
|Subscription request reference
|
|
|-
|Subscription reference
|Local identifier of the subscription. Not needed but can be useful in exception flows
|
|}

===== Message ‘Subscription error’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|
|
|-
|Request type
|Subscribe / unsubscribe
|
|-
|Error timestamp
|
|
|-
|Error message
|Subscribe: company unknown, (participant not authorized)

Unsubscribe: company unknown, company not active, subscription unknown, subscription not active
|
|-
|Subscription request reference
|
|
|}

==== Design decisions ====

===== Explicit request and preview =====
The nature of the subscription and notification pattern leads to a different use of the explicit request and preview as stated in the SDG-regulation:

* Notification is performed without a user transaction, making real-time explicit request and preview impossible.
* Fraud prevention outweighs user centricity, making explicit request and preview less opportune.
* The public nature of company data relaxes the need of explicit request and preview.

Implementing an explicit request for future notifications introduces the burden of creating and maintaining an explicit request administration, with for instance options to retract a previously given explicit request

''Design decision'': for the Business event notification explicit request and preview as defined in the SDG-regulation is not applicable.

===== Positioning of subscription registration =====
For the location of the subscription registration certain options can be considered:

* Fully at the data providing MS: The subscription is registered at the data providing member state. The DE sends messages to the DO via DR and DT to manage the subscription (subscribe, cancel subscription).

* Splitted between data provider and data consuming MS: It is a possibility to split the register; the DO then only registers which MS subscribe to a certain company, and the DC MS registers which DE subscribe to the company. The process flow would be: (1) a central component at the DT registers which DE’s subscribe to which subjects of which data owners; (2) the DT registers as a MS for this company; (3) the DO registers which MS subscribes to which company and sends notifications to the DT (4) the DT distributes the notification to all DE.
* At a central component: The DE4A-architecture implements the four-corner model, a central subscription register would conflict with this principle. Moreover, a subscription is a direct relation between a DO and a DE regarding a subject, there will be no added value to place such a subscription in an external, central component.

''Design decision'': The registration of subscriptions is placed within the data providing member state. DP MS is free to choose in which environment this is (DT, DO or another environment). The assumption for the design of the S&N pattern is that the subscription registration is fully placed in the environment of the DO.

===== Evidence exchange and subscription request =====
The main flow of the DBA-pilot is that the intermediation pattern triggers the subscription and notification pattern. Part of the intermediation pattern is the exchange of evidence: DE requests a specific evidence type from a specific company from the DO. In the happy flow the DE subscribes to receive notifications regarding this company. This trigger can be implemented in different ways:

* As a part of the request for evidence. The evidence exchange request then consists at least of: company identifier, requested evidence type, DE identifier, subscribe y/n.

* In a separate subscription request message: after a user consent to the preview and a successful completion of the registration process a separate subscription message is send.

''Design decision'': the subscription request is not combined with the evidence exchange request but is sent after successful registration of the company/branch.

Combining the subscription request with the evidence exchange would be too early in the process. It would lead to (possibly a relative high number of) requests to cancel the subscription if no consent was given or the registration was not successful. This would also introduce the risk of unauthorised subscriptions and notifications if the cancellation fails.

=== Event Notification ===
Business Process (picture)
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|An event regarding the company triggers the notification process. This event can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration as a result of the business event.
|-
|'''Identify DE4A event'''
|DO
|Service
|The DO determines the DE4A Business event name.

Note that the DO must have a mapping of it's own business events to the list of DE4A business events.
|-
|'''Check subscription'''
|DO
|Service
|Check the subscription register for subscribers to the company that is the subject of the business event:

* No active subscriptions: end of process
* Active subscriptions found: continue notification process
|-
|'''Extract evidence'''
|DO
|Service
|Delete this step. (sending evidence or changed data is another type of notification process)
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification, mainly the DE4A business event name and the timestamp the event took place.
|-
|'''Resolve service metadata'''
|DT
|Service
|Move from a list of subscribers to single notifications (one for each subscriber) and lookup the routing information for each notification.
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|Send notification, receive the acknowledgement that the notification has been received by the DR and update the audit log with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|DR performs a technical validation of the event notification and forward it to the DE. A technical exception flow is out of scope of this process description.

Log received message as part of audit trail?
|-
|'''Determine event response'''
|DE
|Service
|Check the notified business event and determine the action to be taken.

Note that every determination result is logged as a part of the audit trail or for internal reasons:

* Company identifier
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or is no longer active. Afterwards this will have to be analysed this to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The business event is not relevant for the DE and is dismissed. No further actions need to be taken.
|-
|'''Update company information'''
|DE
|Service
|THe lookup pattern is triggered to request a new copy of the Company Registration Evidence.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|Notify responsible party or organizational unit (that then contacts the company if needed).

Depends on process, case by case, if this can be automated or manually.
|}

Note:

* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.

==== Messages ====

===== Message ‘Business event notification’ =====
{| class="wikitable"
|'''Element'''
|'''Description'''
|'''Example value'''
|-
|Legal Person Identifier
|Identification of the company following the eIDAS regulation: country code / country code / company identifier
|
|-
|Business event identification
|The identification of the business event (list of value: OOP TS business event catalogue)
|
|-
|Business event timestamp
|Date and time of business event
|
|-
|Subscription reference
|Identification of the subscription as registered at DO (local id) which can be used in communication between DO and DE. Not essential but can be useful in exception flows
|
|}

== Process Realization ==
?All on one Page or do we create sub-pages for Business Process and Process Realization?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]

Subscription and Notification Pattern

2021-05-06T12:17:08Z

Bart.vanbekkum:

Subscription and Notification Pattern

2021-05-06T10:14:43Z

Bart.vanbekkum:

Introductory text

=== Functional Variants of the Subscription and Notification Pattern ===
Two distinct business requirements for Subscription and Notification Pattern: Updating of previously shared Evidence or being informed about an Event

Technically also two different approaches to Notification: Sending updated Data of a defined Evidence type or Event Notifications that contain only the identification data and the event type. Technical approach and business requirement do not relate one two one, giving rise to potential hybrid approaches.

Event The reference Architecture for the DE4A projects focusses the Subscription and Notification Pattern on Event Notification, which can be combines with the [[Lookup Pattern]] to cover the updating previously shared evidence use case. [23-04-2021: tables below still represent a hybrid approach and need rework]

=== Working Hypotheses ===

== Business Process ==

=== Event Subscription ===

Business Process (picture)

Activity Table
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type*'''
|'''Description'''
|-
|'''Trigger initiate subscription'''
|eProcedure
|User
|The eProcedure leads at the side of the data-evaluator to either the registration of the represented company or the registration of a branch of the represented company (the parent-company of the branch).

A successful registration of the company or the branch of the company leads to a subscription to business events of the represented company. This is needed to assess impact of these business events on service delivery to the company or the branch.

The subscription process can also be triggered for technical reasons: for instance to resend subscription requests because an error occurred at DO-side.

|-
|'''Initiate subscription'''
|DE
|Service
|Initiate subscription:

* Collect data and formulate subscription need:
** company identifier
** all events of subset/type of events (specific event catalogue)? tbd
** type of action: subscribe
** period of subscription? tbd
* Forward to Data requestor (if applicable)

Note: subscriber should unsubscribe and re-subscribe if participant-id changes. To be able to do so, subscriptions have to be registered at the DE.

|-
|'''Trigger cancel subscription'''
|eProcedure / Public service / Notification
|Service
|Potential triggers to cancel a subscription are:

* Public service: the delivery of an public service can lead to the need to cancel the subscription (the public service has ended, e.g. a multi-year subsidy procedure, the country can decide to cancel the branch-office registration).

* eProcedure: the user can also withdraw from service and thereby initiating cancellation of the subscription?

* Notification: after receiving a notification the assessment can be that the subscription is no longer needed (exception flow).

* Technical reasons: for instance an error at the DO-side could lead to the need to resend the request to cancel a subscription.
|-
|'''Cancel subscription'''
|DE
|Service
|Cancel subscription:

* Collect data and formulate cancel subscription need:
** company identifier
** all events of subset/type of events (specific event catalogue)? tbd
** type of action: cancel subscription
** specific end-date of the subscription? tbd
* Forward to Data requestor (if applicable)
|-
|'''Lookup event provider routing information'''
|DR
|Service
|Lookup information on competent authority that facilitates subscription service (metadata tbd)

(should data requestor resolve participant id dynamically? Not needed, participant id is stable enough)
|-
|'''Inform National Coordinator that un-subscription was not successful'''
|DR
|User
|In case of the cancellation of a subscription there is a slight chance the participant ID of DO has changed: a manual process deals with this (unhappy) flow.
|-
|'''Send (un)subscription request'''
|DR
|Service
|Send the request to subscribe or unsubscribe to the DT.
|-
|'''Forward (un)subscription error'''
|DR
|Service
|Forward (un)subscription error message received from DT to DE
|-
|'''Investigate reason for (un)subscription error'''
|DE
|User
|Analyse error and take appropriate actions (error could be on side of DE of DO) (exception so no need to model this in detail)
|-
|'''Forward confirmation'''
|DR
|Service
|Forward the confirmation on the (un)subscription request (received from the DT) to the DE.
|-
|'''Log (un)subscription information'''
|DE
|Service
|The confirmation is logged to complete the audit trail.

Note: register in a way that it is easily readable (optional: include subscription id).
|-
|'''Validate (un)subscription request'''
|DT
|Service
|Technical validation including forwarding to data owner. Technical exception out of scope
|-
|'''Evaluate (un)subscription request'''
|DO
|Service
|Functional check of request to subscribe: does company exists, are type of events/subscription supported, is DE authorized.

Functional check of request to unsubscribe: does subscription exists.

If the request does not pass the functional check, the request is rejected.
|-
|'''Prepare (un)subscription error message'''
|DO
|Service
|Collect the content (mainly the link to the request and the error message) and send it to DT
|-
|'''Send (un)subscription error message'''
|DT
|Service
|Forward to DR
|-
|'''Register (un)subscription'''
|DO
|Service
|Data owner creates/ends the DE’s subscription on the company’s events.

Remarks:

* If messages resemble BRIS messages that would avoid extra work to be done; because this mechanism is in already in place
* Harmonised set of business event needed.
* Register on evidence type?
|-
|'''Confirm (un)subscription'''
|DO
|Service
|Create a confirmation: (un)subscription result (success), timestamp, link to (un)subscription request and send to DT (if applicable)
|-
|'''Send (un)subscription confirmation'''
|DT
|Service
|Send confirmation to DR

Log confirmation
|}

* A / M = Automated or Manual

Notes:

* A user centric perspective is that the user can cancel the subscription and prefers to provide the changes in company registration manually. This is out of scope.
* Separation of domains:
* BRIS domain: if a branch of a certain company type (limited company) is registered in the Business Register of MS the consequences are:
* The subscription is already covered by BRIS and legally necessary as long as branch is registered.
* User has no influence on subscription process
* SDG domain, if company is registered at DE:
* subscription and explicit request as long as eProcedure runs? tbd
* BRIS: covers some cases; check at DE if subscription is already covered by BRIS?

=== Event Notification ===
Business Process (picture)
{| class="wikitable"
|'''Activity / UC'''
|'''Role'''
|'''Type'''
|'''Description'''
|-
|'''Trigger Change in registered company'''
|Company representative / SP
|User
|A change in the company registration triggers the notification process. The change in company registration can be initiated by:

* a representative of the company itself, e.g.: merger, change of owner.
* a public service, e.g.: change of postal code, death of representative, court of law ruling.
|-
|'''Change company registration'''
|DO
|User
|Standard process of the Data Owner - Business Register - to process changes in company registration.
|-
|'''Identify event'''
|DO
|Service
|The DO matches the changes in company registration to the business event catalogue (event monitoring), identifies the business event that has taken place and determines which processes are related to the business event.

The DO triggers all process(es) related to the identified event:

* if the change matches with OOP TS event catalogue: continue OOP TS notification process
* if the change matches with other event catalogue(s) (e.g. BRIS): trigger relevant process(es)

Note that changes of the company can be out of scope of the DE4A/DBA-pilot and therefore not lead to a notification.

Note that an event could resort under BRIS and under OOP TS regulation; e.g. a cross-border merger of a company and Bolagsverket and RVO have a subscription on this company: this leads to a BRIS notification to Bolagsverket and an OOP TS notification to RVO.
|-
|'''Check subscription'''
|DO
|Service
|Check the subscription registration for subscribers to the company that is the subject of the business event:

* No active subscriptions: end of process
* Active subscriptions found: continue notification process
|-
|'''Extract evidence'''
|DO
|Service
|Extraction of changed data to include in notification (could be part of prepare notification step).
|-
|'''Prepare notification message and subscriber list'''
|DO
|Service
|Make a list of the subscribers to notify and create the payload of the notification. The payload includes the changed data, so changed data is not missed when different notifications follow shortly after each other. The original value and new value of the changed elements are included and not the whole Company Registration evidence (sometimes the original value is needed (e.g. EUID).
|-
|'''Resolve service metadata'''
|DT
|Service
|Move from a list to single notifications (one for each subscriber) and lookup the routing information for each notification.
|-
|'''Resolve subscriber participant ID and inform National Coordinator'''
|DT
|User
|If address / DE participant id is not found in the metadata, manual action is needed: contact DE / MS of participant id to analyse the exception and take appropriate measures.
|-
|'''Request from DE to resend event notifications'''
|DE
|User
|Exception flow for missed notifications (failed or non-failed): if a DE misses notifications a resend of notifications can be requested.
|-
|'''Resend past event notifications'''
|DT
|User
|The resending of previously sent notifications requires a manual action at the DT.
|-
|'''Send event notification'''
|DT
|Service
|Send notification, receive the acknowledgement that the notification has been received by the DR and update the audit log with both the event notification and the acknowledgement.
|-
|'''Validate event notification'''
|DR
|Service
|DR performs a technical validation of the event notification and forward it to the DE. A technical exception flow is out of scope of this process description.

Log received message as part of audit trail?
|-
|'''Determine event response'''
|DE
|Service
|Check the notified business event and determine the action to be taken.

Note that every determination result is logged as a part of the audit trail or for internal reasons:

* EUID
* Notified event
* Request id
* Determined response
* Timestamp of determination
|-
|'''Request unsubscription'''
|DE
|Service
|When the company cannot be identified or is no longer active. Afterwards this will have to be analysed this to find the cause of this apparently wrong subscription and to take appropriate measures.
|-
|'''Dismiss event'''
|DE
|Service
|The business event is not relevant for the DE and is dismissed. No further actions need to be taken.
|-
|'''Update company information'''
|DE
|Service
|The company data that is registered by the DE is updated, using the information in the notification.
|-
|'''Identify business responses and notify responsible party'''
|DE
|User
|Notify responsible party or organizational unit (that then contacts the company if needed).

Depends on process, case by case, if this can be automated or manually.
|}

Note:

* A functional response from DE to DO, for example to inform that appropriate actions have been taken, are out of scope of DE4A / OOP TS (it is part of BRIS requirements though). Check.
* Notifications from DE to DO (resulting from changes in the branch registration) are out of scope of DE4A / OOP TS.

== Process Realization ==
?All on one Page or do we create sub-pages for Business Process and Process Realization?

== Used by the following use cases ==

[[Use Case "Doing Business in Another Member State" (DBA UC2)|DBA (UC2)]]

== Application collaborations ==

TBD
[[Category:wip]]