Intermediation Pattern
The Intermediation Pattern is one of the cross-border interaction patterns of the DE4A Reference Architecture (cf. D2.1 Architecture Framework). It is used by the following use case: Use Case "Starting a Business in Another Member State" (DBA UC1). The intermediation pattern is largely derived from the High-level technical Architecture (versions 0.1 and 0.2) presented by the CEF Preparatory Action for the Once-only Technical System (OOTS) for tArticle 14 of he Single Digital Gateway Regularion [REF].
Working hypotheses and implementation principles
The Intermediation reference interaction pattern is valid under several working hypotheses, which are based on an architecture analysis and is oriented along the Interdisciplinary Questions identified for the field of cross-border eGovernment interoperbility.
| 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 essential for the intermediation pattern. The DC manages both the interaction with the user and controls the status of all DP evidence retrieval processes. The DC can retain overal control by reacting to responses of the DP (evidence or error) and monitoring the a response is received in a reasonable amount of time (i.e. SLA) |
| 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. | The DE4A pilot cases appear not to be affacted 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 | Once the OOP sequence is started by receipt of an explicit request, the whole OOP exchange is handled in an uninterrupted manner, while the user remains waiting for the evidence. This means that any exception during the OOP exchange leads to the termination of this OOP attempt, potentially to be repeated at a later time as a new attempt.
Notwithstanding the possibility for the eProcedure portal of the DC to offer a “save and resume” functionality, the OOP request itself needs to be repeated in its entirety upon returning to the eProcedure. In this way we keep the save and resume entirely in the control of the single Procedure portal and “simulate” a disrupted procedure case, without the need to manage persistent process instances across a multitude of highly independent systems. |
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 | After 2023 (with SDGR as legal basis), the DP does not need to re-validate the explicit user request, they can rely on the DC to have done so. It is questionable whether this is presently possible in the Pilots, as the SDGR Article 14 enters into force after the Pilot timeline (Article 39). The assumption is, however, that piloting for the SDGR is part of the public authority tasks related to the SDGR (i.e. fall under the application of Article 14 (11)). | We need the MS participating in the pilots to sustain this interpretation and accept the limitation that the pilot solution cannot transition to full production on grounds of this legal basis, before the full Article 14 of the SDGR enters into force on 12.12. 2023. |
| Preview & Approval UI | The preview can be provided, and the user approval collected, by the DC, prior to the evidence being used in eProcedure. It is well understood that the data processing of the evidence on the part of the DC is restricted to providing the preview to the user. This entails the risk that operators of the receiving competent authority could gain, either by accident or (disingenuous) intent, access to the evidence data prior to user authorisation, i.e. for example by using administrator rights on the underlying ICT infrastructure. | There are legal, privacy and security concerns with this hypothesis and there are indications that not all MS are prepared to accept these. A preview provided by the DC would for instance break the privacy-by-design principle.
It is also noteworthy that the DP does not know about the outcome of a DC-side preview or would need to be explicitly informed about it. The preview at the DC side must be able to show previews of evidences from multiple countries and must be implemented for every DC. The DC has in any case to implement a solution guaranteeing that “the data included in the preview should not be stored longer than is technically necessary” (recital 47 SDGR)[3] if the user decides not to reuse or to submit the data. |
| Identity and Record Matching | From experience on MS-level we see that a reasonably good match can result from the use of the (mandatory) eIDAS attributes. The working hypothesis is that this insight can be generalised to all pilot MSs. Two consequences of this hypothesis are that a) the user does not need to provide supplementary attributes and b) a second eIDAS authentication at the DP (potentially multiple DP) is not required. | As the matching based on eIDAS attributes is never 100% it is only considered sufficient from a piloting perspective, where an unsuccessful match could be dropped from the pilot population.
Most MS consider current examples of implementation of record matching as insufficiently matured and scalable across all EU MS. A process has to be defined, for example, to manage the situations where this automatic matching doesn’t work. The Intermediation pattern has limitations for catching these exceptions especially in case of an unsuccessful match at the DP, as no direct interaction between U and DP is foreseen. |
| Transitivity of user identity | After 12.12.2023, the SDGR and the legal task of the DC provide the legal basis for the exchange of user or data subject data from DC to DP. We assume that the development in preparation of the SDGR (i.e. piloting) is part of the public authorities’ tasks covered by the SDGR (i.e. Article 14 (11)), hence that the SDGR provides the legal basis for the pilots.
Adding a GDPR consent in the explicit request is not a valid legal basis for the case that the identification does include personal data of other data subjects than the requestor (e.g. change of address for families). |
IF the intermediation pattern is used in in teh citizen domain, we need the MS participating in the pilots adopting the intermediation pattern to sustain this interpretation. |
| Hand-on of UI between actors | The DC handles all user interaction of the eProcedure, including the OOP transfer of evidence, thus foreclosing the need to hand-over user sessions across MSs. | This means that the pilot cases do not include additional information, other than included in the initial request and (mandatory) eIDAS attributes, to be used by the DP. |
| Mandate and Proxy | The mandate and proxy challenge can be resolved by an extension of the eIDAS node.
A simple solution can be build on the "full powers"-assumption with current eIDAS functionality. |
The results from SEMPER can be adopted for piloting. It is expected that solutions based in this approach cannot go production live within the timelines of DE4A, as it would require an adjustment of the eIDAS Regulation. |
| Encryption Gap | OOP in the public sector does not require true E2E encryption. The exchange between DR and DP 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 | 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, in line with the legal barrier of 'L4: National requirements for original and /or certified copies of evidence' identified in D1.7. | |
| Automated re-use of data | 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-us of data requires establishing canonical evidence definitions. |
| Production system and real-life cases | With reference to SDGR Article 14(11), pilots based on the intermediation pattern can interface with productive systems and use real-life cases (if participants are made aware that they are participating in a DE4A pilot). | Pilots considering the intermediation pattern must align with their participating MS that they accept the interpretation of the Article 14(11) as legal basis of the pilot even before the full Article 14 of the SDGR enters into force on 12.12. 2023.
The situation in the business domain is differnt as the company registration data is already publicly available. |
| Payment for evidence | 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 compenent authorities require payment for issuing evidence. |
| BRIS integration | A technical re-use or bridge to BRIS is not possible because of differences in scope and accessibility by competent authorities other then business registers. The semantic definitions of BRIS can be largely reused. | The pilot system for the Doing Business Abroad Pilot need to be set-up separte from BRIS. |
| Matching evidences between Member States | The final system should support both harmonized and harmonized evidence type and the architecture is taking account of both bases. In the pilot context, focus will be put on establishing deep semantic interoperability through the definition of canonical evidences | Heterogenous, 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 the pilot partners. Each partner needs to implement a transformation from national to canonical evidence. |
| Multi-evidence Cases | The system should support all four multi-evience cases, which means that an array of evidence types and evidences must be included in a single OOP request/response. | 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.
The multi-evidence cases are likely not relevant for the Doing Business Abroad Pilot. Theoretically, the 'Multi Evidence Types'-case could be applied in the second iteration to request e.g. company registration evidence and annual financial statement in a single request. |
Business process collaboration
The figure below models the intermediation pattern in BPM 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.
The activities of all participants are listed in roughly chronological order across all three processes in Table 6 #Business Activities of the Intermediation Pattern below. The conversations between the participants are described in the subsequent two tables 7 #Conversation between User and Data Consumer and 8 #Conversation between Data Consumer and Data Provider.
In this pattern the DC is centre stage, as can easily be seen in the diagram: All user interactions are managed by the DC, acting as the front-office for all other competent authorities involved. The process(es) by potentially several DPs are structurally child-processes of the DC process, which means that the DC needs to retain control of the processes of the DP by tracking their completion, as depicted in the centre of the diagram, using an exclusive event gateway that tracks the desired and alternative DP responses against a SLA timer.
The working hypothesis that the OOP sequence must be executed in an uninterrupted manner is also clearly visible in the diagram: the start (triggered by the explicit OOP request) and end (after user approved preview) are represented by intermediate events; all tasks between these two events are fully automated and any exception flows result in the OOP transfer attempt being stopped (after this is communicated via the DC to the User). Consequently, all ‘save and resume’ functionality is concentrated on the DC Procedure portal and the OOP sequence would need to be repeated in its entirety if unsuccessful on first attempt.
Table 6 #Business Activities of the Intermediation Pattern above lists the business activities of all three processes roughly in chronological order. The first column designates the activities included in the diagram. The second column provides the abbreviation of the responsible role. For a definition of these roles, please refer to Deliverable D2.1 Architecture Framework. The third column contains the task type (see BPMN 2.0 standard specification) as shown in the diagram 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 Intermediation Pattern
| Activity / UC | Role | Type | Description |
| Request or resume (public) service procedure | U | User | 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 | 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 | 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 | 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 | 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 | Exception handling activity: Alternative channel information is displayed to the user and the user exits the e-procedure. |
| Determine procedural requirements | DE | Service | 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 | 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 | 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. |
| 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 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. It should be checked whether the requesting competent authority can reasonably and rightfully request that specific type of evidence. |
| Re-establish user identity | DO | Service | The DO matches the information about the user (i.e. eIDAS mandatory and optional attributes) with the DP country’s records to identify the user in their systems. This amounts to matching the eIDAS attributes to a national identification number. This is a Data Owner activity, because in a distributed scenario the data transferor might not have a legal basis to do so. |
| Communicate non-availability of OOP | DT | Service | 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 | The DO extracts the requested evidence form their registry and forwards it to the DT. |
| Communicate non-availability of evidence | DT | Service | Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA. |
| 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 (i.e. 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. User cannot be uniquely identified – fallback to another channel (i.e. IMI) Evidence not found – Check whether the request specified the correct geographical scope of authority and contact the DP directly if that was the case Evidence transfer blocked for legal or authorization reasons – Contact the DP directly 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 | 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 requested evidence. These statuses should include:
Evidence requested, expected response in x minutes/seconds Preview available (click here) Evidence approved SLA overrun – please try again later User identification failed Evidence not available Evidence expected to be available in y days – please return If a preview is ready for the user this is shown in the overview, including a link (or similar) that allows the user to navigate to the preview. |
| Compose evidence response | DO | Service | The DO prepares the extracted evidence to be send as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, this task includes the translation of the national definitions into the canonical evidence. |
| Transfer evidence | DT | Service | The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR. |
| 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. It must also be established whether the evidence can be used right away, because the exchange is allowed under EU or national law, or must be previewed. |
| Prepare preview | DE | Service | The DE prepares a preview for the U and provides it to UI to be displayed in the User session. |
| Preview evidence | U | User | The user can view the evidence in a UI or UI component (i.e. widget/frame) separate from the actual eProcedure form (i.e. the preview should not be data auto-filled in the eProcedure form itself. This requires an aligned UI framework in the MS. Alternatively, the Preview could be provided in a second window/tab (with consideration for accessibility requirements). In any case, the user can approve the use of the evidence in the eProcedure or can decline the use of the evidence. The U should be reassured that the evidence is not kept by the DC in case of non-approval. |
| Delete evidence | DE | Service | Exception handling activity: An evidence that was declined by the user must be deleted permanently from all systems in the DC MS. |
| Evaluate evidence | DE | Service | 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 | 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. |
| Receive acknowledgement of receipt | U | Receive | The U is waiting to receive the acknowledgment that all required evidence is received by the DC. The acknowledgment is displayed in the eProcedure portal (optionally a copy sent by e-mail or deposited in a government-hosted, secure message box). |
| Submit eProcedure | U | User | 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. |
| Provide public service | DE | Sub-process | This is a subprocess that is very heterogenous 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 | 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 7 #Conversation between User and Data Consumer describes the conversation between U and DC by listing the exchanged messages in chronological order. Table 8 #Conversation between Data Consumer and Data Provider does the same for the conversation between DC and DP. It lies at the core of the Intermediation pattern that there is no direct conversation between U and DP, in contrast to the User-supported Intermediation Pattern and the Verifiable Credentials Pattern.
Conversation between User and Data Consumer
| From | Message | To | Description |
| U | (Public) service request | DC | 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 | Link to UI or identity service provider, potentially to several alternative eID services |
| U | Authentication details | DC | Identity information of the user (i.e. uniqueness ID + identification data set) |
| DC | Alternative channel information | U | 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 | List of evidences (in terms of the DC country) that are required to complete the eProcedure |
| U | Explicit OOP request | DC | 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 | 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 |
| DC | OOP status update (preview ready) | U | Status update that the preview is ready to be viewed including the link to the preview page |
| DC | Evidence preview | U | Rendered preview of the evidence |
| U | Preview response | DC | Accepting or declining of the evidence exchange |
| DC | Evidence missing | U | 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) |
| DC | Acknowledgement of receipt | U | Acknowledgement that all required evidence was submitted and the (public) service can be provided to the user |
| U | (Public) service request (completed) | DC | Complete and final submission of the (public service request), including all required information |
| DC | (Public) service response | U | 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
| From | Message | To | Description |
| DC | Evidence request | DP | Must include user identification (eIDAS attributes, mandatory and possibly optional). Could additionally include the user email for direct communication |
| DP | User unknown | DC | Message that the user could not be identified |
| DP | Evidence not available | DC | Message that the evidence does not exist or could not be retrieved in time |
| DP | Evidence response | DC | The evidence in electronic format |
Process realization
The process realization viewpoint is adapted from the Service Realization Viewpoint mentioned in the ArchiMate 3.1 specification as was described in the Architecture Framework. It is the bridge between business architecture and application architecture in DE4A, defining which application services are required and which Application Collaboration realize these services in order to execute the business activities derived from the business requirements. The Business Activity objects are occurrences of the activities in the Business Process Collaboration.
Figure 5 below shows how the User process (cf. Business Process Collaboration view of the Intermediation Pattern) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented under Application collaborations below.
The User requests (or resumes) a public service via the EProcedure Portal and has to authenticate himself through the Trust Architecture. The user can choose to abort the eProcedure, or, If the authentication is succesful, request a transfer of evidence via the OOP Technical System (EProcedure Portal).
The User can follow the Evidence Status and preview the Evidence once transfered (Evidence Interchange Management). Via the EProcedure Portal the User can save the eProcedure to continue it at a later point in time or abort it altogether if he wishes so. Confirmation reception of the evidence by the DC and finally submission of the eProcedure is also provided by EProcedure Portal after which the Public service can be offered to the User.
Figure 6 below shows how the Data Consumer process (cf. Business Process Collaboration view of the Intermediation Pattern) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented under Application collaborations below.
The DC inititates the authentication if the user in order to establish his identity (Trust Architecture). If this fails the user may be directed to an alternative channel via (EProcedure Portal). If authentication is successful the DC has to determine the procedureal requirements, match those requirements with the Evidence needed en determine what Evidence is already available (all through the EProcedure Portal).
With he help of the Information Desk the required cross-border evidence is determined and the relevant routing information is looked up.
Next the Evidence can be requested, the request message is encrypted and digitally signed using the Trust Architecture. The evidence is exchanged using Data Logistics and its status can be tracked via the Evidence Interchange Management.
The signature of the received message is validated and the message decrypted (Trust Architecture). Via Evidence Interchange Management the evidence is prepared for preview. After approval of the user the evidence can be evaluated by the DC and the public service can be provided to the User. If the User doesn't approve the evidence it must be deleted (also Evidence Interchange UI Integration).
Figure 7 shows how the Data Provider process (cf. Business Process Collaboration view of the Intermediation Pattern) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations which are presented under Application collaborations below.
The Evidence request is received via Data Logistics. With the help of the Trust Architecture the DP checks the signature of the request and decrypts it. An Authority check may be performed using the Information Desk establishing that the DC is allowed to request the evidence type. Next the user identity is re-established using Trust Architecture.
If this successful the evidence is extracted by Evidence Retrieval and transformed to cannonical form (Evidence Portal) . Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by Data Logistics and Evidence Portal.
If all is well the Evidence is prepared for transfer, encrypted and digitally signed using Trust Architecture and ultimately exchanged using Data Logistics.