Difference between revisions of "Application Services"

From DE4A
Jump to navigation Jump to search
m
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== intro text ==
+
''An application service represents an explicitly defined exposed application behaviour. An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces.'' (ArchiMate® Standard, Version 3.1, The Open Group)
 +
 
 +
The Application Service is the linking-pin between the Business Process and the Application Component. These application services are identified in the context of the business process realization viewpoint.
 +
 
 +
In DE4A, Application Service will also be used to provide a functional classification of application behaviour that can be consumed by different business processes. This classification is based on EIRA and TOOP and will be compiled and refined in the context of next task. It will provide the structure of the catalogue of SBBs, which realize this kind of service.
  
Lorem ipsum...
 
  
 
== DE4A solution overview ==
 
== DE4A solution overview ==
  
{| class="wikitable" style="padding:50px"  
+
{| class="wikitable sortable" style="padding:50px"  
 
!Application Service
 
!Application Service
 
!Used in Pattern
 
!Used in Pattern
Line 11: Line 14:
 
!Appl. Component (PSA)  
 
!Appl. Component (PSA)  
 
|-
 
|-
![[Inquire routing information]]
+
![[Inquire Routing Information]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC looks up where to send the request for evidence to. This service acts as an API to lookup the routing information.
 
|Generic. The DC looks up where to send the request for evidence to. This service acts as an API to lookup the routing information.
|Data service lookup
+
|[[Data Service Lookup]]
 
|-
 
|-
![[Cross-border evidence matching]]
+
![[Cross-border Evidence Matching]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC must match required evidence cross-border. This service bundles UI and logic to support this process.
 
|Generic. The DC must match required evidence cross-border. This service bundles UI and logic to support this process.
|Evidence type translator
+
|[[Evidence Type Translator]]
 
|-
 
|-
![[Evidence exception UI]]
+
![[Evidence Exception UI]]
 
|USI, VC
 
|USI, VC
 
|Generic. Through this service the U is informed about errors or delays with respect to the requested evidence and the U is told to return to the eProcedure portal of the DC.
 
|Generic. Through this service the U is informed about errors or delays with respect to the requested evidence and the U is told to return to the eProcedure portal of the DC.
| Evidence portal front-end
+
|[[Evidence Portal Front-end]]
 
|-
 
|-
![[Explicit request]]
+
![[Explicit Request]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The user must make an explicit request for OOP transfer of evidence. This service handles the request.
 
|Generic. The user must make an explicit request for OOP transfer of evidence. This service handles the request.
|eProcedure portal front-end
+
|[[eProcedure Portal Front-end]]
 
|-
 
|-
![[Persistent URL generation]]
+
![[Persistent URL Generation]]
 
|USI
 
|USI
 
|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.
 
|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.
|Evidence portal back-end
+
|[[Evidence Portal Back-end]]
 
|-
 
|-
![[Evidence shredder]]
+
![[Evidence Shredder]]
 
|Inter
 
|Inter
 
|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.  
 
|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.  
|Evidence interchange back-end
+
|[[Evidence Interchange Back-end]]
 
|-
 
|-
![[eProcedure save and resume]]
+
![[eProcedure Save and Resume]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. "Saving the (public) service request to continue at a later point in time is handled by this service. This is an important service making the user’s life easier. An eProcedure application form usually requires the user to provide several inputs, wait for evidence transfers and/or upload documents themselves. The save and resume function allows them to complete the form over several days (up to some limit), saving changes e.g. an SLA timeout on the exchange of evidence, and editing the form again as needed before submitting the final application. Beside this voluntarily choice there is also the case that things go wrong: a timeout on the exchange of evidence, a system that is down, network errors etc. The save and resume functionality also supports to recover from some error situations preventing that the user must start all over again.
 
|Generic. "Saving the (public) service request to continue at a later point in time is handled by this service. This is an important service making the user’s life easier. An eProcedure application form usually requires the user to provide several inputs, wait for evidence transfers and/or upload documents themselves. The save and resume function allows them to complete the form over several days (up to some limit), saving changes e.g. an SLA timeout on the exchange of evidence, and editing the form again as needed before submitting the final application. Beside this voluntarily choice there is also the case that things go wrong: a timeout on the exchange of evidence, a system that is down, network errors etc. The save and resume functionality also supports to recover from some error situations preventing that the user must start all over again.
|Session Management
+
|[[Procedure Management]]
 
|-
 
|-
![[eProcedure submission]]
+
![[eProcedure Submission]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. After all evidence is available and the requirements of the procedure have been fulfilled the user can submit the request. This service bundles UI and handling of request submission.
 
|Generic. After all evidence is available and the requirements of the procedure have been fulfilled the user can submit the request. This service bundles UI and handling of request submission.
|eProcedure portal front-end
+
|[[eProcedure Portal Front-end]]
 
|-
 
|-
![[eProcedure termination]]
+
![[eProcedure Termination]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. An eProcedure can be aborted. This service terminates the requested eProcedure (public) service.
 
|Generic. An eProcedure can be aborted. This service terminates the requested eProcedure (public) service.
|eProcedure portal front-end
+
|[[eProcedure Portal Front-end]]
 
|-
 
|-
![[Message decryption]]
+
![[Message Decryption]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. Both DC and DP decrypt messages to allow for secure cross-border exchanges of data. This service handles decryption of data (symmetrical, asymmetrical or a combination).
 
|Generic. Both DC and DP decrypt messages to allow for secure cross-border exchanges of data. This service handles decryption of data (symmetrical, asymmetrical or a combination).
|Data encryption/decryption
+
|[[Data Encryption/Decryption]]
 
|-
 
|-
![[Message encryption]]
+
![[Message Encryption]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. Both DC and DP encrypt messages to allow for secure cross-border exchanges of data. This service handles encryption of data (symmetrical, asymmetrical or a combination).
 
|Generic. Both DC and DP encrypt messages to allow for secure cross-border exchanges of data. This service handles encryption of data (symmetrical, asymmetrical or a combination).
|Data encryption/decryption
+
|[[Data Encryption/Decryption]]
 
|-
 
|-
 
![[e-Signature Verification and Validation Service]]
 
![[e-Signature Verification and Validation Service]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. Both DC and DP verify/validate eSignatures supported by this service. Shares the functionality of the verification of documents that are signed electronically. An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. ‘validation’ means the process of verifying and confirming that an electronic signature is valid.
 
|Generic. Both DC and DP verify/validate eSignatures supported by this service. Shares the functionality of the verification of documents that are signed electronically. An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. ‘validation’ means the process of verifying and confirming that an electronic signature is valid.
|Trust Service Provisioning Component
+
|[[Trust Service Provisioning]]
 
|-
 
|-
![[Alternative channel]]
+
![[Alternative Channel]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. If the user identity cannot be established the user is redirected to an alternative channel. This service supports the handling of this.
 
|Generic. If the user identity cannot be established the user is redirected to an alternative channel. This service supports the handling of this.
|eProcedure portal back-end
+
|[[eProcedure Portal Back-end]]
 
|-
 
|-
 
![[e-Signature Creation Service]]
 
![[e-Signature Creation Service]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. Shares the functionality of signing data in electronic form, e.g. by using PKI based certificates. In EIRA sense it means signed by a natural person, no legal person, and an ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign.
 
|Generic. Shares the functionality of signing data in electronic form, e.g. by using PKI based certificates. In EIRA sense it means signed by a natural person, no legal person, and an ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign.
|Trust Service Provisioning Component
+
|[[Trust Service Provisioning Component]]
 
|-
 
|-
 
![[Data Exchange Service]]
 
![[Data Exchange Service]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. Shares the functionality that enables the secure exchange of messages, records, forms and other kinds of data between different ICT systems. This includes data routing, except endpoint discovery
 
|Generic. Shares the functionality that enables the secure exchange of messages, records, forms and other kinds of data between different ICT systems. This includes data routing, except endpoint discovery
|Data Exchange Component
+
|[[Data Exchange]]
 
|-
 
|-
![[eProcedure confirmation]]
+
![[eProcedure Confirmation]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The acknowledgment that all required evidence is received by the DC is confirmed to the U by this service.
 
|Generic. The acknowledgment that all required evidence is received by the DC is confirmed to the U by this service.
|eProcedure portal front-end
+
|[[eProcedure Portal Front-end]]
 
|-
 
|-
![[Authentication initiation]]
+
![[Authentication Initiation]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The DC asks the user to authenticate him/herself. This service initiates the authentication process.
 
|Generic. The DC asks the user to authenticate him/herself. This service initiates the authentication process.
|Identity Management Component
+
|[[Identity Management]]
 
|-
 
|-
![[Procedural requirements determination]]
+
![[Procedural Requirements Determination]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The DC determines the applicable requirements for a procedure. This service supports this requirements determination and bundles UI and logic to do so.
 
|Generic. The DC determines the applicable requirements for a procedure. This service supports this requirements determination and bundles UI and logic to do so.
|eProcedure rules engine
+
|[[eProcedure Rules Engine]]
 
|-
 
|-
![[Legal basis check (2x)]]
+
![[Legal Basis Check (2x)]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC establishes for both the request and the preview whether this is allowed under applicable Union or national law in which case no user request or approval is needed.
 
|Generic. The DC establishes for both the request and the preview whether this is allowed under applicable Union or national law in which case no user request or approval is needed.
|Authorization controller
+
|[[Authorization Controller]]
 
|-
 
|-
![[Evidence request tracker]]
+
![[Evidence Request Tracker]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC establishes the technical availability of evidence. Was some piece of evidence received, did a timeout occur (SLA) or was an error code returned by the DP? This service keeps track of requested evidence.
 
|Generic. The DC establishes the technical availability of evidence. Was some piece of evidence received, did a timeout occur (SLA) or was an error code returned by the DP? This service keeps track of requested evidence.
|Evidence interchange back-end
+
|[[Evidence Interchange Back-end]]
 
|-
 
|-
![[Evidence status tracker]]
+
![[Evidence Status Tracker]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC keeps track of evidence requested versus evidence received. This service bundles the UI and logic to support this.
 
|Generic. The DC keeps track of evidence requested versus evidence received. This service bundles the UI and logic to support this.
|Evidence interchange back-end
+
|[[Evidence Interchange Back-end]]
 
|-
 
|-
![[Available evidence determination]]
+
![[Available Evidence Determination]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The DC looks what required evidence is already available for the user on national level (doesn’t have to be requested). This service includes querying national base registers for available evidence.
 
|Generic. The DC looks what required evidence is already available for the user on national level (doesn’t have to be requested). This service includes querying national base registers for available evidence.
|eProcedure rules engine
+
|[[eProcedure Rules Engine]]
 
|-
 
|-
![[Requirements/evidence matching (2x)]]
+
![[Requirements/Evidence Matching (2x)]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The DC matches the requirements with available evidence. This service bundles UI and logic to match the requirements with available evidence in order to establish if there is a delta (missing evidence). The first use of this service takes place after establishing the procedural requirements (i.e. evidence already available in the DC MS), the second use is after evidence collection to establish completeness (i.e. then also including exchanged evidence)."
 
|Generic. The DC matches the requirements with available evidence. This service bundles UI and logic to match the requirements with available evidence in order to establish if there is a delta (missing evidence). The first use of this service takes place after establishing the procedural requirements (i.e. evidence already available in the DC MS), the second use is after evidence collection to establish completeness (i.e. then also including exchanged evidence)."
|eProcedure rules engine
+
|[[eProcedure Rules Engine]]
 
|-
 
|-
![[Evidence status overview]]
+
![[Evidence Status Overview]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The DC updates the evidence status. This is supported by this service.
 
|Generic. The DC updates the evidence status. This is supported by this service.
|Evidence interchange front-end
+
|[[Evidence Interchange Front-end]]
 
|-
 
|-
![[Evidence lookup]]
+
![[Evidence Lookup]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The DP has to extract the evidence from some registry. This service bundles the functionality to look up and retrieve the evidence from a DP or central MS registry.
 
|Generic. The DP has to extract the evidence from some registry. This service bundles the functionality to look up and retrieve the evidence from a DP or central MS registry.
|Evidence query
+
|[[Evidence Query]]
 
|-
 
|-
![[Extended identity matching UI]]
+
![[Extended Identity Matching UI]]
 
|USI, VC
 
|USI, VC
 
|Generic. The U is presented with a UI in order to provide additional information in order to do the identity matching. This service handles this.
 
|Generic. The U is presented with a UI in order to provide additional information in order to do the identity matching. This service handles this.
|Record Matching
+
|[[Record Matching]]
 
|-
 
|-
 
![[eProcedure Initiation]]
 
![[eProcedure Initiation]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. The user can start a specific eProcedure to receive a public service and provide an initial set of information. The service bundles UI and handling of the data provided by the user.
 
|Generic. The user can start a specific eProcedure to receive a public service and provide an initial set of information. The service bundles UI and handling of the data provided by the user.
|eProcedure portal front-end
+
|[[eProcedure Portal Front-end]]
 
|-
 
|-
 
![[Evidence Preview]]
 
![[Evidence Preview]]
 
|Inter, USI
 
|Inter, USI
 
|Generic. The user must be able to preview and approve the evidence. This service bundles UI and approval handling before the DC can use the evidence.
 
|Generic. The user must be able to preview and approve the evidence. This service bundles UI and approval handling before the DC can use the evidence.
|Evidence interchange front-end
+
|[[Evidence Interchange Front-end]]
 
|-
 
|-
 
![[User Authentication (UI)]]
 
![[User Authentication (UI)]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Generic. User Interface for entering credentials, e.g. user/password, to be used for authentication purposes.
 
|Generic. User Interface for entering credentials, e.g. user/password, to be used for authentication purposes.
|Identity Management Component
+
|[[Identity Management]]
 
|-
 
|-
![[Identity/record matching]]
+
![[Identity/Record Matching]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|Some identity matching is foreseen on both DC and DP side based on eIDAS attributes (mandatory and possibly optional attributes) as well as (maybe) additional attributes to establish the identity of the user in some MS local registry. This service deals with the record matching (automatic and/or manually).
 
|Some identity matching is foreseen on both DC and DP side based on eIDAS attributes (mandatory and possibly optional attributes) as well as (maybe) additional attributes to establish the identity of the user in some MS local registry. This service deals with the record matching (automatic and/or manually).
|Record matching
+
|[[Record Matching]]
 
|-
 
|-
![[Authority check]]
+
![[Authority Check]]
 
|Inter
 
|Inter
 
|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).
 
|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).
|Authorization controller
+
|[[Authorization Controller]]
 
|-
 
|-
![[Prepare Preview before transfer]]
+
![[Prepare Preview Before Transfer]]
 
|USI
 
|USI
 
|The DP prepares a preview for the U and displays it in the UI of the evidence portal.
 
|The DP prepares a preview for the U and displays it in the UI of the evidence portal.
|Evidence portal back-end
+
|[[Evidence Portal Back-end]]
 
|-
 
|-
![[Prepare Preview after receiving]]
+
![[Prepare Preview After Receiving]]
 
|Inter
 
|Inter
 
|The DC prepares a preview for the U and displays it in the UI of evidence interchange management.
 
|The DC prepares a preview for the U and displays it in the UI of evidence interchange management.
|Evidence interchange back-end
+
|[[Evidence Interchange Back-end]]
 
|-
 
|-
![[Receive (public) service result]]
+
![[Receive (Public) Service Result]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|The user process end (happy flow) with receiving the result of the (public) service. This service takes care of this.  
 
|The user process end (happy flow) with receiving the result of the (public) service. This service takes care of this.  
 
|N/A
 
|N/A
 
|-
 
|-
![[Error handler]]
+
![[Error Handler]]
 
|Inter, USI, VC
 
|Inter, USI, VC
 
|This application service is used for handling error situations with respect to:
 
|This application service is used for handling error situations with respect to:
 
*non-availability of OOP
 
*non-availability of OOP
 
*non-availability or delay of evidence
 
*non-availability or delay of evidence
|Evidence portal back-end
+
|[[Evidence Portal Back-end]]
 
|}
 
|}

Latest revision as of 10:41, 11 June 2021

An application service represents an explicitly defined exposed application behaviour. An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. (ArchiMate® Standard, Version 3.1, The Open Group)

The Application Service is the linking-pin between the Business Process and the Application Component. These application services are identified in the context of the business process realization viewpoint.

In DE4A, Application Service will also be used to provide a functional classification of application behaviour that can be consumed by different business processes. This classification is based on EIRA and TOOP and will be compiled and refined in the context of next task. It will provide the structure of the catalogue of SBBs, which realize this kind of service.


DE4A solution overview

Application Service Used in Pattern Description (PSA) Appl. Component (PSA)
Inquire Routing Information Inter, USI Generic. The DC looks up where to send the request for evidence to. This service acts as an API to lookup the routing information. Data Service Lookup
Cross-border Evidence Matching Inter, USI Generic. The DC must match required evidence cross-border. This service bundles UI and logic to support this process. Evidence Type Translator
Evidence Exception UI USI, VC Generic. Through this service the U is informed about errors or delays with respect to the requested evidence and the U is told to return to the eProcedure portal of the DC. Evidence Portal Front-end
Explicit Request Inter, USI Generic. The user must make an explicit request for OOP transfer of evidence. This service handles the request. eProcedure Portal Front-end
Persistent URL Generation USI 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. Evidence Portal Back-end
Evidence Shredder Inter 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. Evidence Interchange Back-end
eProcedure Save and Resume Inter, USI, VC Generic. "Saving the (public) service request to continue at a later point in time is handled by this service. This is an important service making the user’s life easier. An eProcedure application form usually requires the user to provide several inputs, wait for evidence transfers and/or upload documents themselves. The save and resume function allows them to complete the form over several days (up to some limit), saving changes e.g. an SLA timeout on the exchange of evidence, and editing the form again as needed before submitting the final application. Beside this voluntarily choice there is also the case that things go wrong: a timeout on the exchange of evidence, a system that is down, network errors etc. The save and resume functionality also supports to recover from some error situations preventing that the user must start all over again. Procedure Management
eProcedure Submission Inter, USI, VC Generic. After all evidence is available and the requirements of the procedure have been fulfilled the user can submit the request. This service bundles UI and handling of request submission. eProcedure Portal Front-end
eProcedure Termination Inter, USI, VC Generic. An eProcedure can be aborted. This service terminates the requested eProcedure (public) service. eProcedure Portal Front-end
Message Decryption Inter, USI Generic. Both DC and DP decrypt messages to allow for secure cross-border exchanges of data. This service handles decryption of data (symmetrical, asymmetrical or a combination). Data Encryption/Decryption
Message Encryption Inter, USI Generic. Both DC and DP encrypt messages to allow for secure cross-border exchanges of data. This service handles encryption of data (symmetrical, asymmetrical or a combination). Data Encryption/Decryption
e-Signature Verification and Validation Service Inter, USI Generic. Both DC and DP verify/validate eSignatures supported by this service. Shares the functionality of the verification of documents that are signed electronically. An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. ‘validation’ means the process of verifying and confirming that an electronic signature is valid. Trust Service Provisioning
Alternative Channel Inter, USI, VC Generic. If the user identity cannot be established the user is redirected to an alternative channel. This service supports the handling of this. eProcedure Portal Back-end
e-Signature Creation Service Inter, USI Generic. Shares the functionality of signing data in electronic form, e.g. by using PKI based certificates. In EIRA sense it means signed by a natural person, no legal person, and an ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. Trust Service Provisioning Component
Data Exchange Service Inter, USI Generic. Shares the functionality that enables the secure exchange of messages, records, forms and other kinds of data between different ICT systems. This includes data routing, except endpoint discovery Data Exchange
eProcedure Confirmation Inter, USI, VC Generic. The acknowledgment that all required evidence is received by the DC is confirmed to the U by this service. eProcedure Portal Front-end
Authentication Initiation Inter, USI, VC Generic. The DC asks the user to authenticate him/herself. This service initiates the authentication process. Identity Management
Procedural Requirements Determination Inter, USI, VC Generic. The DC determines the applicable requirements for a procedure. This service supports this requirements determination and bundles UI and logic to do so. eProcedure Rules Engine
Legal Basis Check (2x) Inter, USI Generic. The DC establishes for both the request and the preview whether this is allowed under applicable Union or national law in which case no user request or approval is needed. Authorization Controller
Evidence Request Tracker Inter, USI Generic. The DC establishes the technical availability of evidence. Was some piece of evidence received, did a timeout occur (SLA) or was an error code returned by the DP? This service keeps track of requested evidence. Evidence Interchange Back-end
Evidence Status Tracker Inter, USI Generic. The DC keeps track of evidence requested versus evidence received. This service bundles the UI and logic to support this. Evidence Interchange Back-end
Available Evidence Determination Inter, USI Generic. The DC looks what required evidence is already available for the user on national level (doesn’t have to be requested). This service includes querying national base registers for available evidence. eProcedure Rules Engine
Requirements/Evidence Matching (2x) Inter, USI, VC Generic. The DC matches the requirements with available evidence. This service bundles UI and logic to match the requirements with available evidence in order to establish if there is a delta (missing evidence). The first use of this service takes place after establishing the procedural requirements (i.e. evidence already available in the DC MS), the second use is after evidence collection to establish completeness (i.e. then also including exchanged evidence)." eProcedure Rules Engine
Evidence Status Overview Inter, USI, VC Generic. The DC updates the evidence status. This is supported by this service. Evidence Interchange Front-end
Evidence Lookup Inter, USI, VC Generic. The DP has to extract the evidence from some registry. This service bundles the functionality to look up and retrieve the evidence from a DP or central MS registry. Evidence Query
Extended Identity Matching UI USI, VC Generic. The U is presented with a UI in order to provide additional information in order to do the identity matching. This service handles this. Record Matching
eProcedure Initiation Inter, USI, VC Generic. The user can start a specific eProcedure to receive a public service and provide an initial set of information. The service bundles UI and handling of the data provided by the user. eProcedure Portal Front-end
Evidence Preview Inter, USI Generic. The user must be able to preview and approve the evidence. This service bundles UI and approval handling before the DC can use the evidence. Evidence Interchange Front-end
User Authentication (UI) Inter, USI, VC Generic. User Interface for entering credentials, e.g. user/password, to be used for authentication purposes. Identity Management
Identity/Record Matching Inter, USI, VC Some identity matching is foreseen on both DC and DP side based on eIDAS attributes (mandatory and possibly optional attributes) as well as (maybe) additional attributes to establish the identity of the user in some MS local registry. This service deals with the record matching (automatic and/or manually). Record Matching
Authority Check Inter 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). Authorization Controller
Prepare Preview Before Transfer USI The DP prepares a preview for the U and displays it in the UI of the evidence portal. Evidence Portal Back-end
Prepare Preview After Receiving Inter The DC prepares a preview for the U and displays it in the UI of evidence interchange management. Evidence Interchange Back-end
Receive (Public) Service Result Inter, USI, VC The user process end (happy flow) with receiving the result of the (public) service. This service takes care of this. N/A
Error Handler Inter, USI, VC This application service is used for handling error situations with respect to:
  • non-availability of OOP
  • non-availability or delay of evidence
Evidence Portal Back-end