User-supported Intermediation Pattern

The User-supported Intermediation Pattern is one of the cross-border interaction patterns of the DE4A Reference Architecture. It is a user-managed access pattern in terms (cf. D2.1 Architecture Framework). It is 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)

Working hypotheses and implementation principles

The User-supported Intermediation reference interaction pattern is valid under several working hypotheses, which are working hypotheses that are either validated or decided upon by the members of DE4A.

Table 22: User-supported Intermediation pattern working hypothesis 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 PD evidence retrieval processes. The control of the overall process is thus not transferred to the user.
Multiple, complementary, overlapping or conflicting evidence equivalents	Multi-evidence cases must in principle be supported – Identical to Intermediation (see 4.2.1)	Identical to Intermediation (chapter 4.2)
Interrupted vs. Uninterrupted exchange	The assumption can be slightly relaxed in comparison to Intermediation (chapter 4.2), 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 as 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 addition time involved in the direct interaction of the U with the DP in comparison to the Intermediation pattern.	One example of a disrupted 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 might 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 [..].
Explicit request and transitivity between actors	The assumption can be relaxed in comparison to the Intermediation pattern (see 4.2.1)	The user authenticates himself 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 (see 4.2.1)	The preview is provided by the DP.
Identity and Record Matching	The assumption can be relaxed in comparison to the Intermediation pattern (see 4.2.1)	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.
Transitivity of user identity	The assumption can be relaxed in comparison to the Intermediation pattern (see 4.2.1)	The user authenticates himself at the DP.
Hand-on of UI between actors	The DP provides an UI to the DC that the user can navigate to.
Mandate and Proxy	Identical to Intermediation (chapter 4.2), however not relevant for the PSA	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 (see 4.2.1)
Structured data vs. unstructured data	Identical to Intermediation (see 4.2.1)
Automated re-use of data	Identical to Intermediation (see 4.2.1)
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	There might still be unforeseen technical, organisational or legal barriers that make a full production use of the pilot systems impractical for some MSs. DE4A Deliverables. D1.7 [4] [forthcoming] will be an important input into this investigation.

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

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

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, see Table 6
Request authentication	DE	Service	Identical with the Intermediation Pattern, see Table 6
Provide authentication details	U	User	Identical with the Intermediation Pattern, see Table 6
Establish user identity	DE	Service	Identical with the Intermediation Pattern, see Table 6
Redirect user to another channel	DE	Service	Identical with the Intermediation Pattern, see Table 6
Abort eProcedure	U	User	Identical with the Intermediation Pattern, see Table 6
Determine procedural requirements	DE	Service	Identical with the Intermediation Pattern, see Table 6
Request OOP transfer of evidence	U	User	Identical with the Intermediation Pattern, see Table 6
Determine required cross-border evidence	DE	Service	Identical with the Intermediation Pattern, see Table 6
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. This might not be generalized to all potential cases (cf. OOTS target architecture), not the least for exchanges that do not require user preview and approval
Generate URL for direct user interaction	DO	Service	The DP generates a URL as landing place for the U to navigate 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.
Provide authentication details for evidence retrieval	U	User	The U uses the means available to him to provide the authentication details. This can happen to 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- of 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, see Table 6
Extract evidence	DO	Service	Identical with the Intermediation Pattern, see Table 6
Communicate non-availability of evidence	DT	Service	Identical with the Intermediation Pattern, see Table 6
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, see Table 6
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 and OOP transfer of evidence is not be 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, see Table 6
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, see Table 6
Save or abort (public) service request	U	User	Identical with the Intermediation Pattern, see Table 6
Submit eProcedure	U	User	Identical with the Intermediation Pattern, see Table 6
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, see Table 6
Receive (public) service result	U	Receive	Identical with the Intermediation Pattern, see Table 6

Application collaborations

eProcedure portal

Evidence portal

Evidence Interchange Management

Trust architecture

Data Logistics

Evidence retrieval