Tomaz.klobujar at 12:12, 13 December 2022

2022-12-13T12:12:49Z

Ictu alexander.bielowski at 12:15, 18 November 2021

2021-11-18T12:15:03Z

Ictu alexander.bielowski at 09:27, 23 September 2021

2021-09-23T09:27:30Z

Ictu harold.metselaar at 10:49, 19 July 2021

2021-07-19T10:49:19Z

Ictu harold.metselaar at 10:48, 19 July 2021

2021-07-19T10:48:46Z

Ictu harold.metselaar at 10:47, 19 July 2021

2021-07-19T10:47:14Z

Ictu harold.metselaar: Created page with "TODO import excel table"

2021-07-19T10:45:19Z

Created page with "TODO import excel table"

New page

TODO import excel table

@@ Line 132: / Line 132: @@
 |The  re-direct URL is now included in the information desk
 |Needs validation in 2nd iteration
+|SA1, SA2
 |-
 |20

@@ Line 131: / Line 131: @@
 |Information  Desk
 |The  re-direct URL is now included in the information desk
+|Needs validation in 2nd iteration
+|
 |-

@@ Line 4: / Line 4: @@
 |'''Principle/Application  collaboration'''
 |'''Implication/Exception'''
-|'''Implication/Exception'''
+|Discription
 |'''Use  case/pattern'''
 |-
@@ Line 131: / Line 131: @@
 |Information  Desk
 |The  re-direct URL is now included in the information desk
+|
+|
 |}

@@ Line 1: / Line 1: @@
 DE4A Architecture Log
 {| class="wikitable"
-|#
+|'''#'''
-|Principle/Application  collaboration
+|'''Principle/Application  collaboration'''
-|Implication/Exception
+|'''Implication/Exception'''
-|Implication/Exception
+|'''Implication/Exception'''
-|Use  case/pattern
+|'''Use  case/pattern'''
 |-
 |1

← Older revision		Revision as of 10:48, 19 July 2021
Line 1:		Line 1:
		+	DE4A Architecture Log
	{\| class="wikitable"		{\| class="wikitable"
	\|#		\|#

← Older revision		Revision as of 10:47, 19 July 2021
Line 1:		Line 1:
−	~~TODO import excel table~~	+	{\| class="wikitable"
		+	\|#
		+	\|Principle/Application collaboration
		+	\|Implication/Exception
		+	\|Implication/Exception
		+	\|Use case/pattern
		+	\|-
		+	\|1
		+	\|Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person
		+	\|Implication: reauthentication
		+	\|This principle assumes automated data exchange on the basis of automatic match of the used person eID with the unique identifiers used in the authentic sources. Automatic identity matching is not always possible and may require re-authentication of the users at DP.
		+	\|SA1, SA2, SA3
		+	\|-
		+	\|2
		+	\|Principle:Data minimisation
		+	\|Implication: selection of the appropriate pieces of evidence
		+	\|Multiple pieces of evidence of the same type can exist at a DP, for example when a student has two diplomas in different fields and only one of them is suitable to be submitted to the DC as part of the application.
		+	\|SA1, SA2, SA3
		+	\|-
		+	\|3
		+	\|Principle:Data minimisation
		+	\|Deviation: additional data in evidence
		+	\|Lack of common evidence schemes across EU means that more data than necessary might be included in evidence, e.g. certificate of completion of secondary education.
		+	\|SA1, SA2, SA3
		+	\|-
		+	\|4
		+	\|Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority
		+	\|Implication: multiple authorities
		+	\|The evidence can be stored at several places, for example universities issue diplomas to students, however the competent authorities for this type of evidence can also be national or regional registries of diplomas operated by Ministries or other relevant bodies.
		+	\|SA1, SA2, SA3
		+	\|-
		+	\|5
		+	\|Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority
		+	\|Implication: single request
		+	\|Member States can establish brokers that connect to different competent authorities, for examples those issuing academic (record of academic results) and non-academic (household status) evidence. In such cases, there can be only one request and transfer required for several pieces of evidence owned by different competent authorities.
		+	\|SA1, SA2, SA3
		+	\|-
		+	\|6
		+	\|Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person
		+	\|Implication: sending an image for previewing
		+	\|The DBA pilot focusses on exchange of structured and machine processable data. In some cases, for previewing purposes, the DC will present the user with the official document on screen as well. This is an image of the document the user is familiar with in current practise (like unstructured data in a PDF).
		+	As an implication of this architectural principle, the image should be integrated in the exchange of structured data. In other words, DBA expects the image to be one of the data elements in the evidence definition. The data provider should guarantee that the data incorporated in the image is identical to the structured data sent. Furthermore, the technical system should allow for swift transport of such images to prevent unacceptable waiting times for the user.
		+	\|DBA1
		+	\|-
		+	\|7
		+	\|Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person
		+	\|Deviation: data is not concerning the user
		+	\|This principle assumes the data exchanged is on the user itself and the user has authenticated with his/her eID. In the DBA pilots there are two deviations:
		+	1. The data exchanged is on the company and not on the user (the representative).
		+	2. Not in all cases the user will be authenticated, e.g. when updating company data after receiving a notification from the data provider.
		+	No matching of the natural person eID with the unique identifier from the authentic source is foreseen.
		+	\|DBA1, DBA2
		+	\|-
		+	\|8
		+	\|Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person
		+	\|Implication: company identification via eIDAS
		+	\|It is of course crucial that information from the correct company will be provided. The member state identifying the company should provide a company identifier that the business register uses to identify the company as well. Translated to eIDAS: the eIDAS LegalPersonIdentifier should be the company identifier in the business register of the data providing member state. This way, the data consumer can send the eIDAS LegalPersonIdentifier to the data provider 1-on-1.
		+	The DBA pilot assumes no ‘company identity matching’.
		+	\|DBA1, DBA2
		+	\|-
		+	\|9
		+	\|Principle:Digital by default
		+	\|Deviation: paper-based procedures are not accepted
		+	\|This principle states ‘this does not mean that the user should be obliged to use the online administrative procedure’. This is obviously true for services to citizens, but not to companies.
		+	Some Member States, like NL, require companies to use digital services. Digital is not only default, but mandatory as well.
		+	\|DBA1
		+	\|-
		+	\|10
		+	\|Principle:One-Only Principle
		+	\|Implication: re-design of customer journey
		+	\|This principle states that multiple administrative procedures must be re-analysed in the context of the complete customer journey. Fortunately, this approach has been widely adopted by many Member States already for services to companies. Company portals (business portals / PSC) offer services to companies to be fulfilled by several service providers.
		+	\|DBA1
		+	\|-
		+	\|11
		+	\|Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority
		+	\|Deviation: some authentic data will be copied
		+	\|This principle states that data from authentic sources should preferably not be copied by the data consumer. In the doing business abroad cases, it is – for the foreseeable future – inevitable that basic company information will be copied. This information is needed for multiple services and service providers, at the time of use as well as later in the process. These DV processes cannot rely on external sources of company data fully. Fortunately, basic company information does not change often.
		+	To keep the company as updated as possible, the doing business abroad architecture defined two mechanisms for updating data:
		+	To keep the company as updated as possible, the doing business abroad architecture defined two mechanisms for updating data:
		+	1. Each time the user authenticates to the company portal, the company portal will retrieve up-to-date company data to check whether company attributes have been changed.
		+	2. When supported by the data provider: a notification mechanism from the data provider to the data consumer will be sent in case of a change in company data (subscription & notification pattern).
		+	\|DBA1, DBA2
		+	\|-
		+	\|12
		+	\|Principle:Mobile first
		+	\|Deviation: desktop first implementation
		+	\|Most of the administrative tasks performed by companies doing business abroad are performed using desktop pc’s. That will not change soon. The DBA pilot will learn from mobile design and implement mobile design elements whenever useful, e.g. implement a responsive design. But, in case mobile-first-elements may weaken the desktop-experience, the latter prevails.
		+	\|DBA1
		+	\|-
		+	\|13
		+	\|Principle:Data control by the user
		+	\|Deviation: when updating company data, the user should not be in control
		+	\|The subscription & notification pattern doesn’t involve users. In a sense, when notifying and updating in this pattern the user is not controlling the data at that point in time. Furthermore, sending data from the data provider to the data consumer is not necessarily in the interest of the user/company, e.g. when the company portal needs to be updated in order to prevent fraud, end financial support, impose additional taxes, etc. Additional legal analysis is required to examine the conditions under which use of the OOP technical system is allowed for updates.
		+	\|DBA2
		+	\|-
		+	\|14
		+	\|Principle:Reuse before build
		+	\|Deviation: BRIS will not be used
		+	\|There is a difficulty in reusing existing components built under different directives/regulations. Existing components must be extended/changed and retested. This is not always cheaper and might lead to unwanted compromises and complexity. Furthermore, this is not always legally possible.
		+	BRIS has been developed for inter-business register communication only and has been – legally – limited to certain pre-defined data-elements. Furthermore, the commission is assessing new concepts to replace the BRIS network that exists today.
		+	The DBA pilot will not use the BRIS network but will use the BRIS semantics as much as possible.
		+	\|DBA1, DBA2
		+	\|-
		+	\|15
		+	\|Principle:Data control by the user
		+	\|Implication: requested evidences might contain user data for other natural persons than the requestor.
		+	\|This principle states the user has a maximum degree of control over his personal data. In case of self-employed / sole traders / single person entities, company data will be personal as well. The company address may be the home address of the person running the company for example.
		+	The user will not be in control of this personal data in all cases. The importance of data exchange for safe economic operation might prevail over personal privacy (e.g. to prevent fraud). In any case, data exchange on any company must always comply with the GDPR requirements.
		+	\|DBA1, DBA2
		+	\|-
		+	\|16
		+	\|Principle:Digital by default
		+	\|Deviation: Paper-based procedures are sometimes necessary
		+	\|In some member states, evidences are no readily available via online services. The reasons may be national law or lagging digitalization. Evidences must in some cases be digitized from paper-based sources before they can be made available in online services.
		+	\|MA1, MA2
		+	\|-
		+	\|17
		+	\|Principle:Once-Only Principle
		+	\|Implication: re-design of customer journey
		+	\|This principle states that multiple administrative procedures must be re-analysed in the context of the complete customer journey. There are ongoing activities in many member states to take a more user-centric approach when designing services. However, much work remains to be done.
		+	\|MA1
		+	\|-
		+	\|18
		+	\|Principle:Mobile first
		+	\|Deviation: no mobile first implementation
		+	\|Designing for mobile first may not be the best solution for users where there is a lot of information to enter or preview.
		+	\|MA1
		+	\|-
		+	\|19
		+	\|Information Desk
		+	\|The re-direct URL is now included in the information desk
		+	\|
		+	\|
		+	\|}