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.
| 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.
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
| 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 |
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
| From | Message | To | Description |
| U | (Public) service request | DC | Identical with the Intermediation Pattern, see Table 24 |
| DC | Authentication request | U | Identical with the Intermediation Pattern, see Table 24 |
| U | Authentication details | DC | Identical with the Intermediation Pattern, see Table 24 |
| DC | Alternative channel information | U | Identical with the Intermediation Pattern, see Table 24 |
| DC | Request for evidence | U | Identical with the Intermediation Pattern, see Table 24 |
| U | Explicit OOP request | DC | Identical with the Intermediation Pattern, see Table 24 |
| 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, see Table 24 |
| U | (Public) service request (completed) | DC | Identical with the Intermediation Pattern, see Table 24 |
| DC | Acknowledgement of receipt | U | Identical with the Intermediation Pattern, see Table 24 |
| DC | (Public) service response | U | Identical with the Intermediation Pattern, see Table 24 |
Conversation between Data Consumer and Data Provider
| From | Message | To | Description |
| DC | Evidence request | DP | Identical with the Intermediation Pattern, see Table 25 |
| DP | Evidence portal URL | DC | Identical with the Intermediation Pattern, see Table 25 |
| DP | User unknown | DC | Identical with the Intermediation Pattern, see Table 25 |
| DP | Evidence not available | DC | Identical with the Intermediation Pattern, see Table 25 |
| DP | Evidence response | DC | The evidence in electronic format – Identical with the Intermediation Pattern, see Table 25 |
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 (cf. Figure 15) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented in section 4.3.4. Table 27 describes the application services.
The following diagram shows how the Data Consumer process (cf. Figure 15) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented in section 4.3.4. Table 27 describes the application services.
The following diagram shows how the Data Provider process (cf. Figure 15) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented in in section 4.3.4. Table 27 describes the application services.
| Application Service | Serves Role | Description | Specialization of Source | Realized by Application Collaboration |
| eProcedure Initiation | U | Generic service, see 17. | DE4A specific | eProcedure Portal |
| User Authentication (UI) | U | Generic service, see 11. | EIRA | Trust Architecture |
| eProcedure termination | U | Generic service, see 16. | DE4A specific | eProcedure Portal |
| Explicit request | U | Generic service, see 34. | DE4A specific | eProcedure Portal |
| Evidence status overview | U (2x), DC (2x) | Generic service, see 2. | DE4A specific | Evidence interchange management |
| Extended identity matching UI | U | Generic service, see 24. | DE4A specific | Trust Architecture |
| Evidence exception UI | U | Generic service, see 33. | DE4A specific | Evidence Portal |
| Evidence preview | U | Generic service, see 18. | DE4A specific | Evidence interchange management |
| eProcedure save and resume | U | Generic service, see 8. | DE4A specific | eProcedure Portal |
| eProcedure submission | U | Generic service, see 19. | DE4A specific | eProcedure Portal |
| eProcedure confirmation | U | Generic service, see 20. | DE4A specific | eProcedure Portal |
| Receive (public) service result | U | Identical to Intermediation pattern, see section 4.2.3 | DE4A specific | eProcedure Portal |
| Authentication initiation | DC, DP | Generic service, see 6.
The difference for USI is that the DP now also initiates user authentication. |
EIRA | Trust Architecture |
| Identity/record matching | DC, DP | Generic service, see 5. | DE4A specific | Trust Architecture |
| Alternative channel | DC | Generic service, see 22. | DE4A specific | eProcedure Portal |
| Procedural requirements determination | DC | Generic service, see 21. | DE4A specific | eProcedure Portal |
| Requirements/evidence matching | DC | Generic service, see 4. | DE4A specific | eProcedure Portal |
| Available evidence determination | DC | Generic service, see 23. | DE4A specific | eProcedure Portal |
| Cross-border evidence matching | DC | Generic service, see 31. | DE4A specific | Information Desk |
| Legal basis check | DC | Generic service, see 12. | DE4A specific | Information Desk |
| Inquire routing information | DC | Generic service, see 28. | DE4A specific | Information Desk |
| Evidence status tracker | DC | Generic service, see 13. | DE4A specific | Evidence interchange management |
| Message encryption | DC, DP | Generic service, see 9. | DE4A specific | Trust Architecture |
| e-Signature Creation Service | DC, DP | Generic service, see 3. | EIRA | Trust Architecture |
| Evidence Request tracker | DC | Generic service, see 27. | DE4A specific | Evidence interchange management |
| Data Exchange Service | DC (2x),
DP (3x) |
Generic service, see 1.
In the USI pattern the DP has an extra usage of this service. |
EIRA | Data Logistics |
| Message decryption | DC, DP | Generic service, see 14. | DE4A specific | Trust Architecture |
| e-Signature Verification and Validation Service | DC, DP | Generic service, see 15. | EIRA | Trust Architecture |
| persistent URL generation | DP | A persistent URL is generated for the purpose of navigation. Based on this URL the DC can forward/redirect the U to the portal of the DP for the required evidence. | DE4A specific | Evidence Portal |
| Prepare Preview | DP | The DP prepares a preview for the U and displays it in the UI of the evidence portal. | DE4A specific | Evidence Portal |
| Evidence lookup | DP | Generic service, see 7. | DE4A specific | Evidence retrieval |
| Error handler | DP | Generic service, see 10. | DE4A specific | Evidence Portal |