Difference between revisions of "User-supported Intermediation Pattern"
Jump to navigation
Jump to search
m |
(Pasted content from D2.4) |
||
| Line 1: | Line 1: | ||
| − | User-supported Intermediation Pattern | + | The User-supported Intermediation Pattern is one of the cross-border interaction patterns of the DE4A [[Reference Architecture]]. It is <span style="background:yellow">a user-managed access pattern in terms</span> (cf. [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf 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, <span style="background:yellow">which are working hypotheses that are either validated or decided upon by the members of DE4A</span>. | ||
| + | {| class="wikitable" | ||
| + | |+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 == | |
| − | + | ==Application collaborations== | |
| − | |||
| − | |||
| − | |||
| − | == Application collaborations == | ||
[[eProcedure portal]] | [[eProcedure portal]] | ||
Revision as of 16:32, 8 June 2021
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. |