Difference between revisions of "Application Services"
Jump to navigation
Jump to search
m |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 72: | Line 72: | ||
|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 | + | |[[Trust Service Provisioning]] |
|- | |- | ||
![[Alternative Channel]] | ![[Alternative Channel]] | ||
| Line 87: | Line 87: | ||
|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 | + | |[[Data Exchange]] |
|- | |- | ||
![[eProcedure Confirmation]] | ![[eProcedure Confirmation]] | ||
| Line 97: | Line 97: | ||
|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 | + | |[[Identity Management]] |
|- | |- | ||
![[Procedural Requirements Determination]] | ![[Procedural Requirements Determination]] | ||
| Line 157: | Line 157: | ||
|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 | + | |[[Identity Management]] |
|- | |- | ||
![[Identity/Record Matching]] | ![[Identity/Record Matching]] | ||
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:
|
Evidence Portal Back-end |