Intermediation Pattern
The 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 case: Use Case "Starting a Business in Another Member State" (DBA UC1).
Working hypotheses and implementation principles
The Intermediation reference interaction pattern is valid under several working hypotheses, which are based on preliminary analysis and many have still to be fully 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 essential for the intermediation pattern. The DC manages both the interaction with the user and controls the status of all DP evidence retrieval processes. |
| Multiple, complementary, overlapping or conflicting evidence equivalents | Multi-evidence cases 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. | It is to be investigated whether the pilot cases and MS combinations of the pilots entail multi-evidence cases at all. If that is not the case, the MVP could be restricted to a single request to single evidence case. |
| 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 in a later 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 that still needs to be validated from a legal point of view and the limitation that the pilot solution cannot transition to full production use 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 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 (change of address for families). |
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. | The possibility to use results from SEMPER is being investigated. It will be sought to minimise the real risk that solutions based on this pattern cannot go production live within the timelines of DE4A, as it would require an adjustment of the eIDAS Regulation.
Reuse would require establishing formal relationships between the two parallel pilot projects SEMPER and DE4A. |
| 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. | |
| 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. | |
| 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. |
| Payment for evidence | In the context of the pilots we assume (at least for the first pilot iteration) that no payments are required. |
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 roughly in chronological order across all three processes in the table #Business Activities of the Intermediation Pattern below. The conversations between the participants are described in the subsequent two tables (#Conversation between User and Data Consumer and #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.
The table #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). |
#Conversation between User and Data Consumer describes the conversation between U and DC by listing the exchanged messages in chronological order. #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.
The following diagram shows how the User process (cf. ) 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.2.4 below. In Table 9 the application services are described.
Figure 5 Process Realization of the User Process
The diagram hereunder shows how the Data Consumer process (cf. Figure 4) 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.2.4 below. In Table 9 the application services are described.
Figure 6 Process Realization of the DC Process
The diagram underneath shows how the Data Provider process (cf. Figure 4) 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.2.4 below. In Table 9 the application services are described.
Figure 7: Process Realization of the DP Process
Table 9 describes the Application Services required to execute the Intermediation Pattern. An application service defines an explicitly exposed application behaviour. An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces or user interfaces.
| 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 request, see 34. | DE4A specific | eProcedure Portal |
| Evidence status overview | U, DC | Generic service, see 2. | DE4A specific | Evidence interchange management |
| Evidence preview | U, DC | Generic service, see 18. | DE4A specific | Evidence interchange management |
| eProcedure save and resume | U | Generic service, see 8.
Also see the application collaboration in Figure 8. |
DE4A specific | eProcedure Portal |
| eProcedure confirmation | U | Generic service, see 20. | DE4A specific | eProcedure Portal |
| eProcedure submission | U | Generic service, see 19. | DE4A specific | eProcedure Portal |
| Receive (public) service result | U | The user process end (happy flow) with receiving the result of the (public) service. This service takes care of this. | DE4A specific | |
| Authentication initiation | DC | Generic service, see 6. | 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 |
| 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 (2x) |
Generic service, see 1. | 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 |
| Evidence shredder | DC | For various reasons (request by user or established time limit for the data) evidence must be deleted. This service bundles UI and logic to support this. | DE4A specific | Evidence interchange management |
| Evidence status tracker | DC | Generic service, see 13. |
|
Evidence interchange management |
| Authority check | DP | The DP establishes that the DC can request the evidence. This service handles the lookup of authorisation. At the moment we consider the possibility for this check to be specific to the evidence type, i.e. is authority A allowed to request evidence type X (cf. Authority to evidence matrix in Table 13). | DE4A specific | Information Desk |
| Evidence lookup | DP | Generic service, see 7. | DE4A specific | Evidence retrieval |