Intermediation Pattern - Revision history

Ictu alexander.bielowski: /* Conversation between User and Data Consumer */

2021-07-06T17:57:46Z

Conversation between User and Data Consumer

Ictu alexander.bielowski: /* Conversation between User and Data Consumer */

2021-07-06T14:17:58Z

Conversation between User and Data Consumer

Ictu alexander.bielowski: /* Business Activities of the Intermediation Pattern */

2021-07-06T13:57:34Z

Business Activities of the Intermediation Pattern

Ictu alexander.bielowski: /* Working hypotheses and implementation principles */

2021-07-06T13:11:17Z

Working hypotheses and implementation principles

Ictu alexander.bielowski: /* Working hypotheses and implementation principles */

2021-07-06T12:40:37Z

Working hypotheses and implementation principles

Ictu mavi.cristache at 09:58, 1 July 2021

2021-07-01T09:58:29Z

Ictu mavi.cristache: /* Working hypotheses and implementation principles */

2021-06-29T08:48:33Z

Working hypotheses and implementation principles

Ictu mavi.cristache: /* Process realization */ typos

2021-06-29T08:35:09Z

Process realization: typos

Ictu mavi.cristache: typo

2021-06-29T08:34:12Z

typo

Ictu mavi.cristache: typos

2021-06-28T22:07:39Z

typos

@@ Line 331: / Line 331: @@
 |Authentication request
 |U
-|Link to UI or identity service provider,  potentially to several alternative eID services
+|Link to UI of identity service provider,  potentially to several alternative eID services
 |-
 |U

@@ Line 381: / Line 381: @@
 |Acknowledgement of receipt
 |U
-|Acknowledgement that all required evidence  was submitted and the (public) service can be provided to the user
+|Acknowledgement that the eProcedure was submitted and the (public) service can be provided to the user
 |-
 |U

@@ Line 300: / Line 300: @@
 |U
 |Receive
-|The U is waiting to receive the acknowledgment that their (public) service request is received in order and that the service will be provided, oftentimes incl. an indication of the expected time needed. The acknowledgment can be is displayed in the eProcedure portal or sent by e-mail or deposited in a government-hosted, secure message box or a combination of the above.
+|The U is waiting to receive the acknowledgment that their (public) service request is received in order and that the service will be provided, oftentimes incl. an indication of the expected time needed. The acknowledgment can be displayed in the eProcedure portal or sent by e-mail or deposited in a government-hosted, secure message box or a combination of the above.
 |-
 |Provide public service

@@ Line 87: / Line 87: @@
 |-
 |Matching evidences between Member States
-|The final system should support both harmonized and harmonized evidence type and the architecture is taking account of both bases. In the pilot context, focus will be put on establishing deep semantic interoperability through the definition of canonical evidences
+|The final system should support both harmonized and non-harmonized evidence type and the architecture is taking account of both bases. In the pilot context, focus will be put on establishing deep semantic interoperability through the definition of canonical evidences
 |Heterogeneous, national evidence types do not need to be matched in run-time.
 For all evidence types in DE4A, a canonical form must be defined an agreed between the pilot partners.

@@ Line 29: / Line 29: @@
 |-
 |Preview & Approval UI
-|The preview can be provided, and the user approval  collected, by the DC, prior to the evidence being used in eProcedure. It is  well understood that the data processing of the evidence on the part of the  DC is restricted to providing the preview to the user. This entails the risk  that operators of the receiving competent authority could gain, either by  accident or (disingenuous) intent, access to the evidence data prior to user  authorisation, i.e. for example by using administrator rights on the  underlying ICT infrastructure.
+|The preview can be provided, and the user approval  collected, by the DC, prior to the evidence being used in eProcedure. It is  well understood that the data processing of the evidence on the part of the  DC is restricted to providing the preview to the user. This entails the risk  that operators of the receiving competent authority could gain, either by  accident or (disingenuous) intent, access to the evidence data prior to user  authorisation.
 |There are legal, privacy and security concerns with  this hypothesis and there are indications that not all MS are prepared to  accept these. A preview provided by the DC would for instance break the  privacy-by-design principle.

@@ Line 253: / Line 253: @@
 |DO
 |Service
-|The DO prepares the extracted evidence to be send as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, this task includes the translation of the national definitions into the canonical evidence.
+|The DO prepares the extracted evidence to be sent as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, this task includes the translation of the national definitions into the canonical evidence.
 |-
 |Transfer evidence

@@ Line 58: / Line 58: @@
 |Mandate and Proxy
 |The mandate and proxy challenge can be resolved by  an extension of the eIDAS node.
-A simple solution can be build on the "full powers"-assumption with current eIDAS functionality.
+A simple solution can be built on the "full powers"-assumption with current eIDAS functionality.
 |The results from SEMPER can be adopted for piloting. It is expected that solutions based in this approach cannot go production live within the timelines of DE4A, as it would require an adjustment of the eIDAS Regulation.
 |-

@@ Line 435: / Line 435: @@
 Figure 6 below shows how the Data Consumer process (cf. [https://wiki.de4a.eu/index.php/File:Intermediation_pattern.png Business Process Collaboration view of the Intermediation Pattern]) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented under [[Intermediation Pattern#Application collaborations|Application collaborations]] below.   [[File:Intermediation Process Realization - DC.png|alt=Figure 6 Process Realization of the DC Process|center|thumb|800x800px|Figure 6: Process Realization of the DC Process]]
-The DC initiates the authentication of the user in order to establish his identity ([[Trust Architecture]]). If this fails the user may be directed to an alternative channel via ([[EProcedure Portal]]). If authentication is successful the DC has to determine the procedural requirements, match those requirements with the Evidence needed and determine what Evidence is already available (all through the [[EProcedure Portal]]).
+The DC initiates the authentication of the user in order to establish his identity ([[Trust Architecture]]). If this fails, the user may be directed to an alternative channel via ([[EProcedure Portal]]). If authentication is successful the DC has to determine the procedural requirements, match those requirements with the Evidence needed and determine what Evidence is already available (all through the [[EProcedure Portal]]).
-With he help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.
+With the help of the [[Information Desk]] the required cross-border evidence is determined and the relevant routing information is looked up.
 Next the Evidence can be requested, the request message is encrypted and digitally signed using the [[Trust Architecture]]. The evidence is exchanged using [[Data Logistics]] and its status can be tracked via the [[Evidence Interchange Management|Evidence Interchange Management.]]

@@ Line 429: / Line 429: @@
 Figure 5 below shows how the User process (cf. [https://wiki.de4a.eu/index.php/File:Intermediation_pattern.png Business Process Collaboration view of the Intermediation Pattern]) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented under [[Intermediation Pattern#Application collaborations|Application collaborations]] below.
 [[File:Intermediation Process Realization - User.png|alt=Figure 5 Process Realization of the User Process|center|thumb|800x800px|Figure 5: Process Realization of the User Process]]
-The User requests (or resumes) a public service via the [[EProcedure Portal]] and has to authenticate himself through the [[Trust Architecture]]. The user can choose to abort the eProcedure, or, If the authentication is successful, request a transfer of evidence via the OOP Technical System ([[EProcedure Portal]]).
+The User requests (or resumes) a public service via the [[EProcedure Portal]] and has to authenticate himself through the [[Trust Architecture]]. The user can choose to abort the eProcedure, or, if the authentication is successful, request a transfer of evidence via the OOP Technical System ([[EProcedure Portal]]).
 The User can follow the Evidence Status and preview the Evidence once transferred ([[Evidence Interchange Management]]). Via the [[EProcedure Portal]] the User can save the eProcedure to continue it at a later point in time or abort it altogether if they wish so. Confirmation reception of the evidence by the DC and finally submission of the eProcedure is also provided by [[EProcedure Portal]] after which the Public service can be offered to the User.