Difference between revisions of "User-supported Intermediation Pattern"

From DE4A
Jump to navigation Jump to search
 
(84 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
User Supported Intermediation
+
The User-supported Intermediation Pattern is one of the cross-border interaction patterns of the DE4A [[Reference Architecture]]. It is used by the following use cases:
  
−
Used by the following use cases.
+
*[[Use Case "Request Address Change" (MA UC1)]]
 +
*[[Use Case "Request an Extract or Copy of a Civil State Certificate" (MA UC2)]]
 +
*[[Use Case "Request Pension Information - Claim Pension" (MA UC3)]]
 +
*[[Use Case "Application to Public Higher Education" (SA UC1)]]
 +
*[[Use Case "Applying for Study Grant" (SA UC2)]]
  
−
[[MA (UC1)]]
+
==Working hypotheses and implementation principles==
 +
The User-supported Intermediation (USI) reference interaction pattern is valid under several working hypotheses. They can be considered a tool for understanding the implications of applying the USI and should be considered by the partners participating in the use cases mentioned above.
 +
{| class="wikitable"
 +
|+Table 22: User-supported Intermediation pattern working hypotheses and implementation principles
 +
|'''Interdisciplinary Topic'''
 +
|'''Hypothesis / Principle'''
 +
|'''Implications and Limitations'''
 +
|-
 +
|Orchestration / Choreography
 +
|The DC is orchestrating the overall flow. This means  that the (potentially multiple) processes on DP side are child processes of  the process on the DC side.
 +
|This is also essential for the user-supported  intermediation pattern. The DC manages the interaction with the user in  context of the eProcedure and controls the status of all DP evidence  retrieval processes. The control of the overall process is thus not  transferred to the user.
 +
|-
 +
|Complementary, overlapping or conflicting  evidence equivalents
 +
|Cases of ambiguous evidences must in principle be supported by the technical system. Deep analysis on whether they are jointly valid or are contradicting each other is left to the public service provider and not included as functionality in the cross-border OOP sequence.
 +
|Identical to [[Intermediation Pattern|Intermediation]].
 +
The DE4A pilot cases appear not to be affected by this issue and the canonical evidence approach also means that this issue is usually resolved at the DP-side. Ambiguous, multiple evidences are still possible in a three-country case, which could be piloted in the second iteration.
 +
|-
 +
|Interrupted vs. Uninterrupted exchange
 +
|The assumption can be slightly relaxed in comparison to [[Intermediation Pattern|Intermediation]], as the direct interaction between U and DP  makes it easier to communicate delays transparently.
  
−
[[MA (UC2)]]
+
In order to prevent that process instances, need to  be kept alive across multiple platforms in multiple MS, we treat the  interdependencies similar to the [[Intermediation Pattern]]. This means that  if the evidence is delayed, i.e. because it is not yet available in digital  form, a second essentially independent request needs to be issued in a later attempt.
  
−
[[MA (UC3)]]
+
A “save and resume” functionality on the side of the  eProcedure portal of the DC becomes, arguably, more important, because of the  higher probability that the eProcedure session hits a time-out during the additional time involved in the direct interaction of the U with the DP in comparison to  the Intermediation pattern.
 +
|One example of an interrupted procedure is evidence  that is not readily available in a digital format [..] said to be out of scope of the SDGR, however appears to be a frequent case for older evidence  that resides still in paper archives. We could consider a subprocess at the DP that digitizes the requested evidence and informs the user (e.g. via a  direct e-mail) about the evidence now being available in a digital format  [..]. This is, however, outside of the scope of DE4A piloting
 +
|-
 +
|Explicit request and transitivity between actors
 +
|The assumption can be relaxed in comparison to the Intermediation pattern.
 +
|The user authenticates themself at the DP and explicitly  sustains the request issued to the DC.
 +
|-
 +
|Preview & Approval UI
 +
|The assumption can be relaxed in comparison to the Intermediation pattern: The preview is provided by the DP, prior to the evidence being sent.
 +
|The preview is provided by the DP.
 +
The preview must only show previews of evidences from the DP themselves. Nevertheless, a national preview solution that is shared by all DP in that country could be considered as an efficient solution.
 +
|-
 +
|Identity and Record Matching
 +
|The assumption can be relaxed in comparison to the Intermediation pattern: The direct user interaction with the DP makes soliciting additional information easier.
 +
|In case of a user authentication at the DP, using an  eID of the DP country, record matching is not needed. If eIDAS is used, then  the DP can solicit additional information from the U to perform the match as part of the eIDAS authentication session.
 +
|-
 +
|Transitivity of user identity
 +
|The assumption can be relaxed in comparison to the Intermediation pattern: The user identity does not need to be transferred from DC to DP.
 +
|The user authenticates themself at the DP.
 +
|-
 +
|Hand-on of UI between actors
 +
|The DP messages the URL to the DC that the user can navigate to.
 +
|Especially in multi-evidence cases, the DC must display the link to the DP evidence portal to the user. Auto-redirect could only be applicable in single-evidence cases, but the added ease should be balanced with the loss of transparency.
 +
|-
 +
|Mandate and Proxy
 +
|Identical to Intermediation, however not relevant for the DE4A pilots: The mandate and proxy challenge can be resolved by an extension of the eIDAS node.
 +
|The matching of interaction pattern to pilot use  cases means that the DBA pilot is not intending to use the user-supported  intermediation pattern, hence mandates and powers are not in scope.
 +
|-
 +
|Encryption Gap
 +
|Identical to Intermediation: OOP in the public sector does not require full E2E encryption. The exchange between DR and DT must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable.
 +
|This might not hold for cases where the gateway would be outsourced to a private sector subcontractor, which is not foreseen for the DE4A pilots.
 +
|-
 +
|Structured data vs. unstructured data
 +
|Identical to Intermediation:
 +
Evidence is handled as structured data. This is not contradicting the addition of an unstructured or scanned document/certificate as part of the structured data transfer (hybrid approach) for reasons of legal validity
 +
|
 +
|-
 +
|Automated re-use of data
 +
|Identical to Intermediation:
 +
Evidence and its use in public service procedures has legal consequences. We assume that automated re-use without premediated harmonization of evidence data definitions is not applicable for the OOP transfer of evidence between MS.
 +
|To facilitate automated re-use of data requires establishing canonical evidence definitions.
 +
|-
 +
|Production system and real-life cases
 +
|The direct interaction between U and DP allows the  pilot to go live in production under current national legal constraints
 +
|
 +
|-
 +
|Payment for evidence
 +
|Identical to Intermediation: In the context of the pilots we assume that no payments are required.
 +
|This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence.
 +
|-
 +
|Matching evidences between Member States
 +
|Identical to Intermediation: The final system should support both harmonized and unharmonized 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.
  
−
[[SA (UC1)]]
+
Each partner needs to implement a transformation from national to canonical evidence.
 +
|-
 +
|Multi-evidence Cases
 +
|Identical to Intermediation: The system should support all four multi-evidence cases, which means that an array of evidence types and evidences must be included in a single OOP request/response.
 +
Multiple Data Providers: If Data Providers are not highly integrated on MS-level, then the users needs to re-authenticate on several different platforms and perform a preview in different platforms with potentially different look and feel.
  
−
[[SA (UC2)]]
+
Multiple Evidence Types: User needs to authenticate only once at the Data Provider. Data Provider offers Preview for all canonical evidences at the same time.
  
−
----
+
Multiple Evidences of the same type: User previews all canonical evidences at the same time. The user can select a subset of evidences for transfer to the Data Consumer.
  
−
Application collaborations
+
Evidences for multiple subjects: The multiple-subject case (i.e. parent with children) requires a separate record matching for the representation register. We expect that this can be done appropriately, based on the matched record or the user (i.e. parent) and the combination of first name, last name and date of birth of the dependent (i.e. child).
 +
|The second iteration should expand the MVP restriction to a single request to single evidence cases, which requires an update of the Exchange Information Model. It is likely that piloting would focus on simpler cases to show the inclusion of multiple evidences in a single evidence response.
 +
|}
  
−
[[eProcedure portal]]
+
== Business process collaboration ==
 +
Figure 15 models the user-supported intermediation pattern in BPMN notation. It consists of three interacting processes, one for the User (U) – the user journey -, one for the Data Consumer (DC) and one for the Data Provider (DP). The message flow (dashed lines) shows the interactions – the conversation – between these participants.
  
−
[[Evidence portal]]
+
In Table 23 the activities of all participants are listed roughly in chronological order across all three processes. The conversations between the participants are described in Table 24, Table 25 and Table 26, listing the messages between the U and DC (Table 24), between DC and DP (Table 25) and between U and DP (Table 26) respectively.
 +
[[File:User-supported Intermediation process.jpg|alt=Figure 15: Business Process Collaboration view of the User-Supported Intermediation Pattern|center|thumb|799x799px|Figure 15: Business Process Collaboration view of the User-Supported Intermediation Pattern]]
 +
In Table 23 the business activities of all three processes are listed roughly in chronological order from left to right. The first column names the activities shown in Figure 15 above. The second column provides the abbreviation of the responsible role. For a definition of these roles, please refer to the DE4A [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf%7CDE4A Deliverable D2.1 Architecture Framework]. The third column contains the task type (please refer to the BPMN 2.0 standard specification) as shown in <span style="background:yellow">Figure 4 above</span>. Please consider that the task type ‘User’ means that it is a Human/Computer interaction task, not that it is in the responsibility of the User (U) as defined in the Architecture Framework or in Article 3(1) of the SDGR. The fourth column describes the business activity in concise language.
  
−
[[Evidence interchange Managment]]
+
=== Business Activities of the User-supported Intermediation Pattern ===
 +
{| class="wikitable"
 +
|+Table 23: Business Activities of the User-Supported Intermediation Pattern
 +
|'''Activity / UC'''
 +
|'''Role'''
 +
|'''Type'''
 +
|'''Description'''
 +
|-
 +
|Request or resume (public) service  procedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern: The user navigates to the eProcedure in the DC country and requests a (public) service. This means they fill in the required information and start the eProcedure. It is specific to the MS and the eProcedure how much information is provided by the user (i.e. which fields to be filled out) in this activity (i.e. prior to authentication) or when submitting the eProcedure later in the process. Email should be included as means to contact the user or provide updates. If the user is returning to a previously started procedure, the eProcedure will return to original instance after authentication.
 +
|-
 +
|Request authentication
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: The DE requests the U to authenticate themselves. This can happen in two ways, either using eIDAS (default) or using the eID of the DC MS, in case that the U has the national eID of the DC country available (see cases 3) and 4) in Table 4 above). The DE provides both options to the U.
 +
|-
 +
|Provide authentication details
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern: The U uses the means available to them to provide the authentication details. This can happen at the user’s discretion using the eID of the DC MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication. If the user is representing another entity (typically a legal person), this relation is also retrieved as part of this authentication.
 +
|-
 +
|Establish user identity
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: The DE establishes the identity of the U in the DC MS environment. In the eIDAS case, this means that the eIDAS uniqueness ID must be linked to the national identification number used to access the MS registries. In the national eID case, this means that the eIDAS attributes (mandatory and optional) must be retrieved for further use in the process. In case of business user, the company identification must be matched. The match of the representing natural person to a population register is not required in all MS.
 +
|-
 +
|Redirect user to another channel
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: Exception handling activity: The U cannot be identified in an automated way by the DC and alternative digital or non-digital channel information (depending on the eProcedure at hand user and potentially dependent on the type of identification error) is collected and provided to the U.
 +
|-
 +
|Abort eProcedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern: Exception handling activity: Alternative channel information is displayed to the user and the user exits the e-procedure.
 +
|-
 +
|Determine procedural requirements
 +
|DE
 +
|Service<span style="background:#FFFF00"><span>
 +
|Identical with the Intermediation Pattern: 
 +
The DE compares the available information (i.e. in the DC MS registries via the national OOP layer) with the information required by the eProcedure. The result can be a (list of) required evidence, defined in terms of the DC country, which is then displayed to the user as a request to provide the evidence, together with the option for the user to request the evidence via the OOTS.
  
−
[[Trust architecture]]
+
This activity is not trivial and should prevent that we ask a User for evidence that is readily available in the DC MS and might not be available in the OOTS cross-border scope.
  
−
[[Data logistics]]
+
Example: It would not make any sense for a Dutch DC to ask a German national born in the Netherlands to provide a birth certificate (which he could not get via the OOTS as it is not cross-border). A similar situation would be asking a French national with a Belgian university diploma to provide that diploma in order to be admitted for a PhD in another Belgian university.
 +
|-
 +
|Request OOP transfer of evidence
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern: The user choses to request the evidence to be fetched for them using the OOTS – the explicit OOP request. The user also indicates – in a guided way – which MS, and possibly lower administrative level, issues the required evidence. Alternatively, the user could provide (i.e. upload) the evidence, but that would not involve the OOTS at all, so we are not considering this case in the reference architecture.
 +
|-
 +
|Determine required cross-border  evidence
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: The required evidence type (in terms of the DC country) is translated into equivalent evidence types that are issued in a lawful way in the DP country indicated by the user.
 +
|-
 +
|Save (public) service request
 +
|DE
 +
|Service
 +
|The eProcedure and all information  provided by the U is automatically saved, in order for the user to be able to  resume the procedure at a later time, e.g. after a session time-out during  the interaction between the U and the DP.
 +
|-
 +
|Lookup routing information
 +
|DR
 +
|Service
 +
|The DR retrieves the technical routing  information (e.g. eDelivery rooting identifier or URL of the webservice  provider), based on the evidence type (in terms of DP country) and the  issuing competent authority (or geographic scope of authority).
 +
|-
 +
|Request evidence
 +
|DR
 +
|Service
 +
|The DR encrypts, signs and sends the  evidence request to the identified technical data service interface of  (potentially several) DP. The evidence request must include the return URL of  the Evidence Overview in the eProcedure portal, enabling the DP to direct the  U back to the DC eProcedure. It should also include user information that  enables the DP to identify for which user or represented company the evidence  must be issued.
 +
|-
 +
|Evaluate evidence request
 +
|DT
 +
|Service
 +
|The DT receives and decrypts the  request and checks whether the request meets formal requirements and can be  accepted.
  
−
[[Evidence retrieval]]
+
Because of the direct interaction  between U and DP the authority check is not needed, i.e. to check whether the  requesting competent authority can reasonably and rightfully request that  specific type of evidence.
 +
|-
 +
|Generate URL for direct user  interaction
 +
|DO
 +
|Service
 +
|The DP generates a URL as landing place  for the U that is specific for the required evidence type.
 +
|-
 +
|Display link to evidence portal
 +
|DR
 +
|Service
 +
|The link to the specific landing page, received from the DP, is displayed as clickable element (link or button) in  the Evidence Status overview.
 +
|-
 +
|Navigate to evidence portal
 +
|U
 +
|User
 +
|The user clicks on a link to the  evidence portal of the respective DP that is displayed in eProcedure portal  of the DC.
 +
|-
 +
|Request authentication for evidence  retrieval
 +
|DO
 +
|Service
 +
|The DO requests the U for to  authenticate themself. This can happen in two ways, either using eIDAS  (default) or using the eID of the DP MS, in case that the U has the national  eID of the DP country available (case 1 and 2 in Table 4). The case of using the national eID scheme would consequently be  quite common.
 +
 
 +
The DP provides both options to the U.
 +
|-
 +
|Request additional identification attributes
 +
|DO
 +
|Service
 +
|If the User identity cannot be matched, the DO displays to user a UI requesting additional identification attributes to improve the probability of finding a match.
 +
|-
 +
|Provide authentication details for  evidence retrieval
 +
|U
 +
|User
 +
|The U uses the means available to them to provide the authentication details. This can happen at the user’s  discretion using the eID of the DP MS or eIDAS. In the second case, the user  is forwarded to the authentication service of the identity provider of their  means of authentication.
 +
|-
 +
|Re-establish user identity
 +
|DO
 +
|Service
 +
|The DO matches the information about  the user (i.e. eIDAS mandatory and optional attributes) with DP country  records to identify the user in their systems. This amounts to matching the  eIDAS attributes to a national identification number. (If the national eID is  used, this task is skipped).
 +
 
 +
Data Owner activity, because in a  distributed scenario, the data transferor might not have a legal basis to do  so.
 +
|-
 +
|Provide additional identification  information
 +
|U
 +
|User
 +
|Exception handling activity:  Interactive form- or chat-based Q&A for additional identification  information (beyond eIDAS attributes). The requested information clearly  depends on the available information at the data provider.
 +
|-
 +
|Communicate non-availability of OOP
 +
|DT
 +
|Service
 +
|Identical with the Intermediation Pattern:
 +
Exception handling activity: The DT informs the DR that the user cannot be identified unequivocally and the OOTS cannot be used to transfer the evidence.
 +
|-
 +
|Extract evidence
 +
|DO
 +
|Service
 +
|Identical with the Intermediation Pattern: The DO extracts the requested evidence form their registry and forwards it to the DT.
 +
|-
 +
|Communicate non-availability or delay of evidence
 +
|DT
 +
|Service
 +
|Identical with the Intermediation Pattern: Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA.
 +
|-
 +
|Prepare preview
 +
|DO
 +
|Service
 +
|The DO prepares a preview for the U and  displays it in the UI of the evidence portal. In addition, the name of the DE  to which the evidence is to be transferred is displayed, in order to provide  full transparency to the user what exchange he is accepting.
 +
|-
 +
|Receive error or delay notification
 +
|U
 +
|User
 +
|Exception handling activity: The DP  displays error or delay information to the User. These error messages are  listed above in the activity ‘Establish non-availability of OOP’
 +
 
 +
In addition, the exception UI informs  the U to return to the eProcedure portal of the DC.
 +
|-
 +
|Preview evidence pre-transfer
 +
|U
 +
|User
 +
|The user can view the evidence in the  UI of the DP and can either approve or decline the transfer of evidence.  Additionally, the Preview UI informs the User to return to the eProcedure  portal of the DC after accepting the evidence exchange.
 +
|-
 +
|Transfer evidence
 +
|DT
 +
|Service
 +
|Identical with the Intermediation Pattern: The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR.
 +
|-
 +
|Establish non-availability of OOP
 +
|DR
 +
|Service
 +
|Exception handling activity: The DR  catches the negative (non-evidence) response from the DT and establishes the  reason in terms of the DC country system and language:
 +
 
 +
There are potentially several reasons  why an OOP transfer of evidence is not available. The DT communicates  these reasons to the DR in all cases that the evidence request cannot be  fulfilled by sending the digitally available evidence within the agreed SLA  as described above. At the moment we expect at least the following reasons  for such an exception that should be framed in standard error messages or  codes, each one with a corresponding recommendation to the user.
 +
 
 +
1)     User cannot be uniquely identified –  fall back to another channel (i.e. IMI)
 +
 
 +
2)     Evidence not found – Check whether the  request specified the correct geographical scope of authority and contact the  DP directly if that was the case
 +
 
 +
3)     Evidence is not readily available in a  digital format now. Expected time for the evidence to be available is x days  – return after x days and issue a new evidence request
 +
|-
 +
|Update evidence status
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: The DE updates the status of a requested evidence and provides that update to the user in the evidence overview. Additionally, the update could be sent to the user via e-mail, including a link to the status overview page.
 +
|-
 +
|Follow evidence status
 +
|U
 +
|User
 +
|After the user requested the OOP  transfer of evidence, they observe the status of the evidence request on an  evidence status overview. It essentially shows the progress or the request  for each separate evidence requested. These statuses should include:
 +
 
 +
1)     Evidence requested, expected response  in x seconds
 +
 
 +
2)     User input required (click-here {link  to evidence portal})
 +
 
 +
3)     Evidence available
 +
 
 +
4)     SLA overrun – please try again later
 +
 
 +
5)     User identification failed
 +
 
 +
6)     Evidence not available
 +
 
 +
7)     Evidence expected to be available in y  days – please return
 +
 
 +
If user input is required, a link to  the evidence portal of the DP is included for the user to follow.
 +
|-
 +
|Forward evidence
 +
|DR
 +
|Service
 +
|The DR registers the receipt, decrypts  the message and in many cases encrypts the message in a MS specific format to  hand it on to the DE.
 +
|-
 +
|Evaluate evidence
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern: The DE checks whether all requested evidences are available and validates that they conform to the evidence type requested. In the positive scenario that all evidences are available, the DE communicates to the user that the procedure can be submitted. In the negative case that not all evidences are received, the DE communicates this back to the U. The Procedure can then not be completed.
 +
|-
 +
|Save or abort (public) service request
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern:
 +
Exception handling activity: The U is informed that not all required evidence could be received, hence that there are still missing evidences preventing the eProcedure to be completed. It depends (only) on the functionality of the specific eProcedure portal what options are provided to the U. We expect that in most cases the user can save the procedure in order to return at a later stage, to repeat the cross-border OOP request or to provide the missing evidence themselves.
 +
|-
 +
|Submit eProcedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern: The U fills the remaining fields required for the eProcedure. It is specific to the MS and the eProcedure which fields to be filled out in this activity or when requesting the eProcedure at the start of the process.
 +
Usually the U is prompted to verify the provided information in an overview before hitting the Submit button.
 +
|-
 +
|Receive acknowledgement of receipt
 +
|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.
 +
|-
 +
|Provide public service
 +
|DE
 +
|Subprocess
 +
|Identical with the Intermediation Pattern: This is a subprocess that is very heterogeneous in composition and timeline, depending on which public service is provided and by which competent authority. Theoretically, the subprocess could be fully automated in some cases, but typically this is a back-office process involving multiple activities of public servants and might take days to several weeks. In many countries the maximum time for this process is defined by law.
 +
|-
 +
|Receive (public) service result
 +
|U
 +
|Receive
 +
|Identical with the Intermediation Pattern: Once the public service is completed, the result is provided to the U. This communication is fully dependent on the functionalities of the eProcedure portal (e.g. e-mail and/or government-hosted, secure message box).
 +
|}
 +
Table 24 describes the conservation between U and DC by listing the exchanged messages in chronological order. Table 25 does the same for the conversation between DC and DP and Table 26 for U and DP.
 +
 
 +
=== Conversation between User and Data Consumer ===
 +
{| class="wikitable"
 +
|+Table 24: User-Supported Intermediation - Conversation between User and Data Consumer
 +
|'''From'''
 +
|'''Message'''
 +
|'''To'''
 +
|'''Description'''
 +
|-
 +
|U
 +
|(Public) service request
 +
|DC
 +
|Identical with the Intermediation Pattern: The choice of public service requested and an initial set of information from the user required for the initiation of the request (breadth and type of information can vary between MS and requested service and can be substantial in some cases. Essentially this includes all information that the user provides prior to the point in the procedure where authentication is required). Inclusion of e-mail could facilitate (additional) messages to the user.
 +
|-
 +
|DC
 +
|Authentication request
 +
|U
 +
|Identical with the Intermediation Pattern: Link to UI or identity service provider, potentially to several alternative eID services.
 +
|-
 +
|U
 +
|Authentication details
 +
|DC
 +
|Identical with the Intermediation Pattern: Identity information of the user (i.e. uniqueness ID + identification data set).
 +
|-
 +
|DC
 +
|Alternative channel information
 +
|U
 +
|Identical with the Intermediation Pattern: Contact information (e.g. email, telephone or address) of an alternative channel to request the public service or to complete authentication/registration.
 +
|-
 +
|DC
 +
|Request for evidence
 +
|U
 +
|Identical with the Intermediation Pattern: List of evidences (in terms of the DC country) that are required to complete the eProcedure.
 +
|-
 +
|U
 +
|Explicit OOP request
 +
|DC
 +
|Identical with the Intermediation Pattern: Information about the geographic scope of authority for identifying the type of evidence and the data service provider (e.g. which MS ministry, region, municipality).
 +
|-
 +
|DC
 +
|Evidence portal link
 +
|U
 +
|Navigable link to the evidence portal  that the user can follow in order to support the DP in retrieving and  transferring the correct evidence
 +
|-
 +
|DC
 +
|OOP status update (not available)
 +
|U
 +
|Error message to the user (see activity  description) explaining the reason why the evidence could not be retrieved  and recommendation of action. In contrast to the intermediation pattern, the  user was already informed by the DP.
 +
|-
 +
|DC
 +
|Evidence missing
 +
|U
 +
|Identical with the Intermediation Pattern: Message to the user that not all evidence could be retrieved and that they can resume the eProcedure once all evidence can be provided (either by the user or via the system).
 +
|-
 +
|U
 +
|(Public) service request (completed)
 +
|DC
 +
|Identical with the Intermediation Pattern: Complete and final submission of the (public service request), including all required information.
 +
|-
 +
|DC
 +
|Acknowledgement of receipt
 +
|U
 +
|Identical with the Intermediation Pattern: Acknowledgement that all required evidence was submitted and the (public) service can be provided to the user.
 +
|-
 +
|DC
 +
|(Public) service response
 +
|U
 +
|Identical with the Intermediation Pattern: The result of the (public) service, irrespective of how it is provided (post, email, secure message box, personal appearance.
 +
|}
 +
 
 +
=== Conversation between Data Consumer and Data Provider ===
 +
{| class="wikitable"
 +
|+Table 25: User-Supported Intermediation - Conversation between Data Consumer and Data Provider
 +
|'''From'''
 +
|'''Message'''
 +
|'''To'''
 +
|'''Description'''
 +
|-
 +
|DC
 +
|Evidence request
 +
|DP
 +
|Identical with the Intermediation Pattern: Must include user identification (eIDAS attributes, mandatory and possibly optional). Could additionally include the user email for direct communication
 +
|-
 +
|DP
 +
|Evidence portal URL
 +
|DC
 +
|Message containing the persistent URL for user-redirection to the evidence portal
 +
|-
 +
|DP
 +
|User unknown
 +
|DC
 +
|Identical with the Intermediation Pattern: Message that the user could not be identified
 +
|-
 +
|DP
 +
|Evidence not available
 +
|DC
 +
|Identical with the Intermediation Pattern: Message that the evidence does not exist or could not be retrieved in time
 +
|-
 +
|DP
 +
|Evidence response
 +
|DC
 +
|Identical with the Intermediation Pattern: The evidence in electronic format
 +
|}
 +
 
 +
=== Conversation between User and Data Provider ===
 +
{| class="wikitable"
 +
|+Table 26: User-Supported Intermediation - Conversation between User and Data Provider
 +
|'''From'''
 +
|'''Message'''
 +
|'''To'''
 +
|'''Description'''
 +
|-
 +
|U
 +
|User navigation trigger
 +
|DP
 +
|User followed the link to the evidence portal
 +
|-
 +
|DP
 +
|Authentication request
 +
|U
 +
|Link to UI of identify service  provider, potentially to several alternative services
 +
|-
 +
|U
 +
|Authentication details
 +
|DP
 +
|Identity information of the user (i.e.  uniqueness ID + identification data set)
 +
|-
 +
|DP
 +
|Request for additional information
 +
|U
 +
|Depending on the information on record  at the DP this request can include different attributes (e.g. matriculation  number for universities, national identifiers for ministries, maiden name….)
 +
|-
 +
|U
 +
|Additional information
 +
|DP
 +
|The information attribute that the DP  requested to perform the extended identify matching
 +
|-
 +
|DP
 +
|User unknown
 +
|U
 +
|Message that the user could not be  identified
 +
|-
 +
|DP
 +
|Evidence not available
 +
|U
 +
|Message that the evidence is not  existing or could not be retrieved in time
 +
|-
 +
|DP
 +
|Evidence preview
 +
|U
 +
|Rendered preview of the evidence
 +
|-
 +
|U
 +
|Preview response
 +
|DP
 +
|Accepting or declining of the evidence  exchange
 +
|}
 +
 
 +
== Process realization ==
 +
The following diagram shows how the User process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.
 +
[[File:USI Process Realization - User.png|alt=Figure 16: Process Realization of the User process|center|thumb|800x800px|Figure: Process Realization of the User process]]The User requests (or resumes) a public service via the [[EProcedure Portal]] and has to authenticate themself with the help of [[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 with the help of [[Evidence Interchange Management]]. Next the user is redirected to DP ([[Evidence Interchange Management]]) where he has to re-authenticate themself using [[Trust Architecture]], provide additional attributes if needed. Errors or a notification of delay is handled by the [[Evidence Portal]] as well as the preview of the evidence at DP side before it is transferred to the DC. If the user wishes so the eProcedure can be aborted or saved to continue at a later point in  time [[EProcedure Portal|(EProcedure Portal)]]. Finally submission of the eProcedure is also provided by [[EProcedure Portal]] after which the Public service can be offered to the User. The following diagram shows how the Data Consumer process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.[[File:USI Process Realization - DC.png|alt=Figure 17: Process Realization of the Data Consumer process|center|thumb|800x800px|Figure: Process Realization of the Data Consumer process]]
 +
The DC initiates the authentication of the user in order to establish their 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 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]] and exchanged using [[Data Logistics]].
 +
 
 +
The user is forwarded to the DP (see image below). On return of the user  there are two possible outcomes: either the OOP evidence is not available or the evidence was received by the DC (exchanged by [[Data Logistics]]). In both cases the evidence status is updated (through [[Evidence Interchange Management]]).
 +
 
 +
Assuming the happy flow the signature of the received message is validated and the message decrypted (Trust Architecture). Via [[EProcedure Portal]] the evidence is evaluated and if all is well the public service can be provided to the user.
 +
 
 +
The diagram below shows how the Data Provider process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.
 +
[[File:USI Process Realization - DP.png|alt=Figure 18: Process Realization of the Data Provider Process|center|thumb|800x800px|Figure: Process Realization of the Data Provider Process]]The Evidence request is received via [[Data Logistics]] and with the help of [[Trust Architecture]] the DP checks the signature of the request message and decrypts it. The DP generates a persistent URL ([[Evidence Portal]]) for user redirection (from DC to DP). Once the user arrives at DP he has to reauthenticate themself using [[Trust Architecture]]. If needed additional information is needed in order to establish the user's identity. If authentication fails, the non-availability of OOP is communicated to the user via the [[Evidence Portal]].
 +
 
 +
If successful the evidence is looked up in the registry ([[Evidence Retrieval]]) and transformed to canonical format ([[Evidence Portal]]). The evidence might need to be digitised which is communicated as non-availability or delay of the evidence ([[Evidence Portal]]). The [[Evidence Portal]] also takes care of preparing the preview of the evidence. If successful (the user consents to the transfer) the evidence send as an encrypted and signed message ([[Data Logistics]] and [[Trust Architecture]] respectively) .
 +
 
 +
==Application collaborations==
 +
 
 +
[[eProcedure Portal]]
 +
 
 +
[[Evidence Portal]]
 +
 
 +
[[Evidence Interchange Management]]
 +
 
 +
[[Trust Architecture]]
 +
 
 +
[[Data Logistics]]
 +
 
 +
[[Evidence Retrieval]]

Latest revision as of 19:04, 6 July 2021

The User-supported Intermediation Pattern is one of the cross-border interaction patterns of the DE4A Reference Architecture. It is used by the following use cases:

Working hypotheses and implementation principles

The User-supported Intermediation (USI) reference interaction pattern is valid under several working hypotheses. They can be considered a tool for understanding the implications of applying the USI and should be considered by the partners participating in the use cases mentioned above.

Table 22: User-supported Intermediation pattern working hypotheses and implementation principles
Interdisciplinary Topic Hypothesis / Principle Implications and Limitations
Orchestration / Choreography The DC is orchestrating the overall flow. This means that the (potentially multiple) processes on DP side are child processes of the process on the DC side. This is also essential for the user-supported intermediation pattern. The DC manages the interaction with the user in context of the eProcedure and controls the status of all DP evidence retrieval processes. The control of the overall process is thus not transferred to the user.
Complementary, overlapping or conflicting evidence equivalents Cases of ambiguous evidences must in principle be supported by the technical system. Deep analysis on whether they are jointly valid or are contradicting each other is left to the public service provider and not included as functionality in the cross-border OOP sequence. Identical to Intermediation.

The DE4A pilot cases appear not to be affected by this issue and the canonical evidence approach also means that this issue is usually resolved at the DP-side. Ambiguous, multiple evidences are still possible in a three-country case, which could be piloted in the second iteration.

Interrupted vs. Uninterrupted exchange The assumption can be slightly relaxed in comparison to Intermediation, as the direct interaction between U and DP makes it easier to communicate delays transparently.

In order to prevent that process instances, need to be kept alive across multiple platforms in multiple MS, we treat the interdependencies similar to the Intermediation Pattern. This means that if the evidence is delayed, i.e. because it is not yet available in digital form, a second essentially independent request needs to be issued in a later attempt.

A “save and resume” functionality on the side of the eProcedure portal of the DC becomes, arguably, more important, because of the higher probability that the eProcedure session hits a time-out during the additional time involved in the direct interaction of the U with the DP in comparison to the Intermediation pattern.

One example of an interrupted procedure is evidence that is not readily available in a digital format [..] said to be out of scope of the SDGR, however appears to be a frequent case for older evidence that resides still in paper archives. We could consider a subprocess at the DP that digitizes the requested evidence and informs the user (e.g. via a direct e-mail) about the evidence now being available in a digital format [..]. This is, however, outside of the scope of DE4A piloting
Explicit request and transitivity between actors The assumption can be relaxed in comparison to the Intermediation pattern. The user authenticates themself at the DP and explicitly sustains the request issued to the DC.
Preview & Approval UI The assumption can be relaxed in comparison to the Intermediation pattern: The preview is provided by the DP, prior to the evidence being sent. The preview is provided by the DP.

The preview must only show previews of evidences from the DP themselves. Nevertheless, a national preview solution that is shared by all DP in that country could be considered as an efficient solution.

Identity and Record Matching The assumption can be relaxed in comparison to the Intermediation pattern: The direct user interaction with the DP makes soliciting additional information easier. In case of a user authentication at the DP, using an eID of the DP country, record matching is not needed. If eIDAS is used, then the DP can solicit additional information from the U to perform the match as part of the eIDAS authentication session.
Transitivity of user identity The assumption can be relaxed in comparison to the Intermediation pattern: The user identity does not need to be transferred from DC to DP. The user authenticates themself at the DP.
Hand-on of UI between actors The DP messages the URL to the DC that the user can navigate to. Especially in multi-evidence cases, the DC must display the link to the DP evidence portal to the user. Auto-redirect could only be applicable in single-evidence cases, but the added ease should be balanced with the loss of transparency.
Mandate and Proxy Identical to Intermediation, however not relevant for the DE4A pilots: The mandate and proxy challenge can be resolved by an extension of the eIDAS node. The matching of interaction pattern to pilot use cases means that the DBA pilot is not intending to use the user-supported intermediation pattern, hence mandates and powers are not in scope.
Encryption Gap Identical to Intermediation: OOP in the public sector does not require full E2E encryption. The exchange between DR and DT must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable. This might not hold for cases where the gateway would be outsourced to a private sector subcontractor, which is not foreseen for the DE4A pilots.
Structured data vs. unstructured data Identical to Intermediation:

Evidence is handled as structured data. This is not contradicting the addition of an unstructured or scanned document/certificate as part of the structured data transfer (hybrid approach) for reasons of legal validity

Automated re-use of data Identical to Intermediation:

Evidence and its use in public service procedures has legal consequences. We assume that automated re-use without premediated harmonization of evidence data definitions is not applicable for the OOP transfer of evidence between MS.

To facilitate automated re-use of data requires establishing canonical evidence definitions.
Production system and real-life cases The direct interaction between U and DP allows the pilot to go live in production under current national legal constraints
Payment for evidence Identical to Intermediation: In the context of the pilots we assume that no payments are required. This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence.
Matching evidences between Member States Identical to Intermediation: The final system should support both harmonized and unharmonized 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.

Each partner needs to implement a transformation from national to canonical evidence.

Multi-evidence Cases Identical to Intermediation: The system should support all four multi-evidence cases, which means that an array of evidence types and evidences must be included in a single OOP request/response.

Multiple Data Providers: If Data Providers are not highly integrated on MS-level, then the users needs to re-authenticate on several different platforms and perform a preview in different platforms with potentially different look and feel.

Multiple Evidence Types: User needs to authenticate only once at the Data Provider. Data Provider offers Preview for all canonical evidences at the same time.

Multiple Evidences of the same type: User previews all canonical evidences at the same time. The user can select a subset of evidences for transfer to the Data Consumer.

Evidences for multiple subjects: The multiple-subject case (i.e. parent with children) requires a separate record matching for the representation register. We expect that this can be done appropriately, based on the matched record or the user (i.e. parent) and the combination of first name, last name and date of birth of the dependent (i.e. child).

The second iteration should expand the MVP restriction to a single request to single evidence cases, which requires an update of the Exchange Information Model. It is likely that piloting would focus on simpler cases to show the inclusion of multiple evidences in a single evidence response.

Business process collaboration

Figure 15 models the user-supported intermediation pattern in BPMN notation. It consists of three interacting processes, one for the User (U) – the user journey -, one for the Data Consumer (DC) and one for the Data Provider (DP). The message flow (dashed lines) shows the interactions – the conversation – between these participants.

In Table 23 the activities of all participants are listed roughly in chronological order across all three processes. The conversations between the participants are described in Table 24, Table 25 and Table 26, listing the messages between the U and DC (Table 24), between DC and DP (Table 25) and between U and DP (Table 26) respectively.

Figure 15: Business Process Collaboration view of the User-Supported Intermediation Pattern
Figure 15: Business Process Collaboration view of the User-Supported Intermediation Pattern

In Table 23 the business activities of all three processes are listed roughly in chronological order from left to right. The first column names the activities shown in Figure 15 above. The second column provides the abbreviation of the responsible role. For a definition of these roles, please refer to the DE4A Deliverable D2.1 Architecture Framework. The third column contains the task type (please refer to the BPMN 2.0 standard specification) as shown in Figure 4 above. Please consider that the task type ‘User’ means that it is a Human/Computer interaction task, not that it is in the responsibility of the User (U) as defined in the Architecture Framework or in Article 3(1) of the SDGR. The fourth column describes the business activity in concise language.

Business Activities of the User-supported Intermediation Pattern

Table 23: Business Activities of the User-Supported Intermediation Pattern
Activity / UC Role Type Description
Request or resume (public) service procedure U User Identical with the Intermediation Pattern: The user navigates to the eProcedure in the DC country and requests a (public) service. This means they fill in the required information and start the eProcedure. It is specific to the MS and the eProcedure how much information is provided by the user (i.e. which fields to be filled out) in this activity (i.e. prior to authentication) or when submitting the eProcedure later in the process. Email should be included as means to contact the user or provide updates. If the user is returning to a previously started procedure, the eProcedure will return to original instance after authentication.
Request authentication DE Service Identical with the Intermediation Pattern: The DE requests the U to authenticate themselves. This can happen in two ways, either using eIDAS (default) or using the eID of the DC MS, in case that the U has the national eID of the DC country available (see cases 3) and 4) in Table 4 above). The DE provides both options to the U.
Provide authentication details U User Identical with the Intermediation Pattern: The U uses the means available to them to provide the authentication details. This can happen at the user’s discretion using the eID of the DC MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication. If the user is representing another entity (typically a legal person), this relation is also retrieved as part of this authentication.
Establish user identity DE Service Identical with the Intermediation Pattern: The DE establishes the identity of the U in the DC MS environment. In the eIDAS case, this means that the eIDAS uniqueness ID must be linked to the national identification number used to access the MS registries. In the national eID case, this means that the eIDAS attributes (mandatory and optional) must be retrieved for further use in the process. In case of business user, the company identification must be matched. The match of the representing natural person to a population register is not required in all MS.
Redirect user to another channel DE Service Identical with the Intermediation Pattern: Exception handling activity: The U cannot be identified in an automated way by the DC and alternative digital or non-digital channel information (depending on the eProcedure at hand user and potentially dependent on the type of identification error) is collected and provided to the U.
Abort eProcedure U User Identical with the Intermediation Pattern: Exception handling activity: Alternative channel information is displayed to the user and the user exits the e-procedure.
Determine procedural requirements DE Service Identical with the Intermediation Pattern:

The DE compares the available information (i.e. in the DC MS registries via the national OOP layer) with the information required by the eProcedure. The result can be a (list of) required evidence, defined in terms of the DC country, which is then displayed to the user as a request to provide the evidence, together with the option for the user to request the evidence via the OOTS.

This activity is not trivial and should prevent that we ask a User for evidence that is readily available in the DC MS and might not be available in the OOTS cross-border scope.

Example: It would not make any sense for a Dutch DC to ask a German national born in the Netherlands to provide a birth certificate (which he could not get via the OOTS as it is not cross-border). A similar situation would be asking a French national with a Belgian university diploma to provide that diploma in order to be admitted for a PhD in another Belgian university.

Request OOP transfer of evidence U User Identical with the Intermediation Pattern: The user choses to request the evidence to be fetched for them using the OOTS – the explicit OOP request. The user also indicates – in a guided way – which MS, and possibly lower administrative level, issues the required evidence. Alternatively, the user could provide (i.e. upload) the evidence, but that would not involve the OOTS at all, so we are not considering this case in the reference architecture.
Determine required cross-border evidence DE Service Identical with the Intermediation Pattern: The required evidence type (in terms of the DC country) is translated into equivalent evidence types that are issued in a lawful way in the DP country indicated by the user.
Save (public) service request DE Service The eProcedure and all information provided by the U is automatically saved, in order for the user to be able to resume the procedure at a later time, e.g. after a session time-out during the interaction between the U and the DP.
Lookup routing information DR Service The DR retrieves the technical routing information (e.g. eDelivery rooting identifier or URL of the webservice provider), based on the evidence type (in terms of DP country) and the issuing competent authority (or geographic scope of authority).
Request evidence DR Service The DR encrypts, signs and sends the evidence request to the identified technical data service interface of (potentially several) DP. The evidence request must include the return URL of the Evidence Overview in the eProcedure portal, enabling the DP to direct the U back to the DC eProcedure. It should also include user information that enables the DP to identify for which user or represented company the evidence must be issued.
Evaluate evidence request DT Service The DT receives and decrypts the request and checks whether the request meets formal requirements and can be accepted.

Because of the direct interaction between U and DP the authority check is not needed, i.e. to check whether the requesting competent authority can reasonably and rightfully request that specific type of evidence.

Generate URL for direct user interaction DO Service The DP generates a URL as landing place for the U that is specific for the required evidence type.
Display link to evidence portal DR Service The link to the specific landing page, received from the DP, is displayed as clickable element (link or button) in the Evidence Status overview.
Navigate to evidence portal U User The user clicks on a link to the evidence portal of the respective DP that is displayed in eProcedure portal of the DC.
Request authentication for evidence retrieval DO Service The DO requests the U for to authenticate themself. This can happen in two ways, either using eIDAS (default) or using the eID of the DP MS, in case that the U has the national eID of the DP country available (case 1 and 2 in Table 4). The case of using the national eID scheme would consequently be quite common.

The DP provides both options to the U.

Request additional identification attributes DO Service If the User identity cannot be matched, the DO displays to user a UI requesting additional identification attributes to improve the probability of finding a match.
Provide authentication details for evidence retrieval U User The U uses the means available to them to provide the authentication details. This can happen at the user’s discretion using the eID of the DP MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication.
Re-establish user identity DO Service The DO matches the information about the user (i.e. eIDAS mandatory and optional attributes) with DP country records to identify the user in their systems. This amounts to matching the eIDAS attributes to a national identification number. (If the national eID is used, this task is skipped).

Data Owner activity, because in a distributed scenario, the data transferor might not have a legal basis to do so.

Provide additional identification information U User Exception handling activity: Interactive form- or chat-based Q&A for additional identification information (beyond eIDAS attributes). The requested information clearly depends on the available information at the data provider.
Communicate non-availability of OOP DT Service Identical with the Intermediation Pattern:

Exception handling activity: The DT informs the DR that the user cannot be identified unequivocally and the OOTS cannot be used to transfer the evidence.

Extract evidence DO Service Identical with the Intermediation Pattern: The DO extracts the requested evidence form their registry and forwards it to the DT.
Communicate non-availability or delay of evidence DT Service Identical with the Intermediation Pattern: Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA.
Prepare preview DO Service The DO prepares a preview for the U and displays it in the UI of the evidence portal. In addition, the name of the DE to which the evidence is to be transferred is displayed, in order to provide full transparency to the user what exchange he is accepting.
Receive error or delay notification U User Exception handling activity: The DP displays error or delay information to the User. These error messages are listed above in the activity ‘Establish non-availability of OOP’

In addition, the exception UI informs the U to return to the eProcedure portal of the DC.

Preview evidence pre-transfer U User The user can view the evidence in the UI of the DP and can either approve or decline the transfer of evidence. Additionally, the Preview UI informs the User to return to the eProcedure portal of the DC after accepting the evidence exchange.
Transfer evidence DT Service Identical with the Intermediation Pattern: The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR.
Establish non-availability of OOP DR Service Exception handling activity: The DR catches the negative (non-evidence) response from the DT and establishes the reason in terms of the DC country system and language:

There are potentially several reasons why an OOP transfer of evidence is not available. The DT communicates these reasons to the DR in all cases that the evidence request cannot be fulfilled by sending the digitally available evidence within the agreed SLA as described above. At the moment we expect at least the following reasons for such an exception that should be framed in standard error messages or codes, each one with a corresponding recommendation to the user.

1)     User cannot be uniquely identified – fall back to another channel (i.e. IMI)

2)     Evidence not found – Check whether the request specified the correct geographical scope of authority and contact the DP directly if that was the case

3)     Evidence is not readily available in a digital format now. Expected time for the evidence to be available is x days – return after x days and issue a new evidence request

Update evidence status DE Service Identical with the Intermediation Pattern: The DE updates the status of a requested evidence and provides that update to the user in the evidence overview. Additionally, the update could be sent to the user via e-mail, including a link to the status overview page.
Follow evidence status U User After the user requested the OOP transfer of evidence, they observe the status of the evidence request on an evidence status overview. It essentially shows the progress or the request for each separate evidence requested. These statuses should include:

1)     Evidence requested, expected response in x seconds

2)     User input required (click-here {link to evidence portal})

3)     Evidence available

4)     SLA overrun – please try again later

5)     User identification failed

6)     Evidence not available

7)     Evidence expected to be available in y days – please return

If user input is required, a link to the evidence portal of the DP is included for the user to follow.

Forward evidence DR Service The DR registers the receipt, decrypts the message and in many cases encrypts the message in a MS specific format to hand it on to the DE.
Evaluate evidence DE Service Identical with the Intermediation Pattern: The DE checks whether all requested evidences are available and validates that they conform to the evidence type requested. In the positive scenario that all evidences are available, the DE communicates to the user that the procedure can be submitted. In the negative case that not all evidences are received, the DE communicates this back to the U. The Procedure can then not be completed.
Save or abort (public) service request U User Identical with the Intermediation Pattern:

Exception handling activity: The U is informed that not all required evidence could be received, hence that there are still missing evidences preventing the eProcedure to be completed. It depends (only) on the functionality of the specific eProcedure portal what options are provided to the U. We expect that in most cases the user can save the procedure in order to return at a later stage, to repeat the cross-border OOP request or to provide the missing evidence themselves.

Submit eProcedure U User Identical with the Intermediation Pattern: The U fills the remaining fields required for the eProcedure. It is specific to the MS and the eProcedure which fields to be filled out in this activity or when requesting the eProcedure at the start of the process.

Usually the U is prompted to verify the provided information in an overview before hitting the Submit button.

Receive acknowledgement of receipt 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.
Provide public service DE Subprocess Identical with the Intermediation Pattern: This is a subprocess that is very heterogeneous in composition and timeline, depending on which public service is provided and by which competent authority. Theoretically, the subprocess could be fully automated in some cases, but typically this is a back-office process involving multiple activities of public servants and might take days to several weeks. In many countries the maximum time for this process is defined by law.
Receive (public) service result U Receive Identical with the Intermediation Pattern: Once the public service is completed, the result is provided to the U. This communication is fully dependent on the functionalities of the eProcedure portal (e.g. e-mail and/or government-hosted, secure message box).

Table 24 describes the conservation between U and DC by listing the exchanged messages in chronological order. Table 25 does the same for the conversation between DC and DP and Table 26 for U and DP.

Conversation between User and Data Consumer

Table 24: User-Supported Intermediation - Conversation between User and Data Consumer
From Message To Description
U (Public) service request DC Identical with the Intermediation Pattern: The choice of public service requested and an initial set of information from the user required for the initiation of the request (breadth and type of information can vary between MS and requested service and can be substantial in some cases. Essentially this includes all information that the user provides prior to the point in the procedure where authentication is required). Inclusion of e-mail could facilitate (additional) messages to the user.
DC Authentication request U Identical with the Intermediation Pattern: Link to UI or identity service provider, potentially to several alternative eID services.
U Authentication details DC Identical with the Intermediation Pattern: Identity information of the user (i.e. uniqueness ID + identification data set).
DC Alternative channel information U Identical with the Intermediation Pattern: Contact information (e.g. email, telephone or address) of an alternative channel to request the public service or to complete authentication/registration.
DC Request for evidence U Identical with the Intermediation Pattern: List of evidences (in terms of the DC country) that are required to complete the eProcedure.
U Explicit OOP request DC Identical with the Intermediation Pattern: Information about the geographic scope of authority for identifying the type of evidence and the data service provider (e.g. which MS ministry, region, municipality).
DC Evidence portal link U Navigable link to the evidence portal that the user can follow in order to support the DP in retrieving and transferring the correct evidence
DC OOP status update (not available) U Error message to the user (see activity description) explaining the reason why the evidence could not be retrieved and recommendation of action. In contrast to the intermediation pattern, the user was already informed by the DP.
DC Evidence missing U Identical with the Intermediation Pattern: Message to the user that not all evidence could be retrieved and that they can resume the eProcedure once all evidence can be provided (either by the user or via the system).
U (Public) service request (completed) DC Identical with the Intermediation Pattern: Complete and final submission of the (public service request), including all required information.
DC Acknowledgement of receipt U Identical with the Intermediation Pattern: Acknowledgement that all required evidence was submitted and the (public) service can be provided to the user.
DC (Public) service response U Identical with the Intermediation Pattern: The result of the (public) service, irrespective of how it is provided (post, email, secure message box, personal appearance.

Conversation between Data Consumer and Data Provider

Table 25: User-Supported Intermediation - Conversation between Data Consumer and Data Provider
From Message To Description
DC Evidence request DP Identical with the Intermediation Pattern: Must include user identification (eIDAS attributes, mandatory and possibly optional). Could additionally include the user email for direct communication
DP Evidence portal URL DC Message containing the persistent URL for user-redirection to the evidence portal
DP User unknown DC Identical with the Intermediation Pattern: Message that the user could not be identified
DP Evidence not available DC Identical with the Intermediation Pattern: Message that the evidence does not exist or could not be retrieved in time
DP Evidence response DC Identical with the Intermediation Pattern: The evidence in electronic format

Conversation between User and Data Provider

Table 26: User-Supported Intermediation - Conversation between User and Data Provider
From Message To Description
U User navigation trigger DP User followed the link to the evidence portal
DP Authentication request U Link to UI of identify service provider, potentially to several alternative services
U Authentication details DP Identity information of the user (i.e. uniqueness ID + identification data set)
DP Request for additional information U Depending on the information on record at the DP this request can include different attributes (e.g. matriculation number for universities, national identifiers for ministries, maiden name….)
U Additional information DP The information attribute that the DP requested to perform the extended identify matching
DP User unknown U Message that the user could not be identified
DP Evidence not available U Message that the evidence is not existing or could not be retrieved in time
DP Evidence preview U Rendered preview of the evidence
U Preview response DP Accepting or declining of the evidence exchange

Process realization

The following diagram shows how the User process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure 16: Process Realization of the User process
Figure: Process Realization of the User process

The User requests (or resumes) a public service via the EProcedure Portal and has to authenticate themself with the help of 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 with the help of Evidence Interchange Management. Next the user is redirected to DP (Evidence Interchange Management) where he has to re-authenticate themself using Trust Architecture, provide additional attributes if needed. Errors or a notification of delay is handled by the Evidence Portal as well as the preview of the evidence at DP side before it is transferred to the DC. If the user wishes so the eProcedure can be aborted or saved to continue at a later point in time (EProcedure Portal). Finally submission of the eProcedure is also provided by EProcedure Portal after which the Public service can be offered to the User. The following diagram shows how the Data Consumer process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure 17: Process Realization of the Data Consumer process
Figure: Process Realization of the Data Consumer process

The DC initiates the authentication of the user in order to establish their 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 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 and exchanged using Data Logistics.

The user is forwarded to the DP (see image below). On return of the user there are two possible outcomes: either the OOP evidence is not available or the evidence was received by the DC (exchanged by Data Logistics). In both cases the evidence status is updated (through Evidence Interchange Management).

Assuming the happy flow the signature of the received message is validated and the message decrypted (Trust Architecture). Via EProcedure Portal the evidence is evaluated and if all is well the public service can be provided to the user.

The diagram below shows how the Data Provider process is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented below.

Figure 18: Process Realization of the Data Provider Process
Figure: Process Realization of the Data Provider Process

The Evidence request is received via Data Logistics and with the help of Trust Architecture the DP checks the signature of the request message and decrypts it. The DP generates a persistent URL (Evidence Portal) for user redirection (from DC to DP). Once the user arrives at DP he has to reauthenticate themself using Trust Architecture. If needed additional information is needed in order to establish the user's identity. If authentication fails, the non-availability of OOP is communicated to the user via the Evidence Portal.

If successful the evidence is looked up in the registry (Evidence Retrieval) and transformed to canonical format (Evidence Portal). The evidence might need to be digitised which is communicated as non-availability or delay of the evidence (Evidence Portal). The Evidence Portal also takes care of preparing the preview of the evidence. If successful (the user consents to the transfer) the evidence send as an encrypted and signed message (Data Logistics and Trust Architecture respectively) .

Application collaborations

eProcedure Portal

Evidence Portal

Evidence Interchange Management

Trust Architecture

Data Logistics

Evidence Retrieval

Retrieved from ‘https://wiki.de4a.eu/index.php?title=User-supported_Intermediation_Pattern&oldid=2894’