|
|
| (166 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| − | Introduction / description
| + | __NOTOC__ |
| | | | |
| − | == Pilots ==
| + | This toolbox is the central, long-term deliverable of the DE4A Architecture work package and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA<sup>2</sup> and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. |
| | | | |
| − | === [[SA|Studying Abroad]] ===
| + | The image below has clickable sections to jump to other pages like, the DE4A Reference Architecture, patterns, Semantic Solutions, Common Components and Building Blocks. |
| | | | |
| − | === [[DBA|Doing Business Abroad]] ===
| + | <imagemap> |
| | + | File:Service_Interoperability_Solutions_Toolbox.png|thumb|center|900x900px|Clicking on an area in the picture causes the browser to load the appropriate wiki page. |
| | | | |
| − | === [[MA|Moving Abroad]] ===
| + | rect 455 124 541 590 [[Intermediation_Pattern|Intermediation pattern]] |
| | + | rect 558 103 651 562 [[User-supported_Intermediation_Pattern|USI pattern]] |
| | + | rect 672 78 750 548 [[Verifiable_Credentials_Pattern|VC pattern]] |
| | + | rect 765 57 853 523 [[Subscription_and_Notification_Pattern|S&N pattern]] |
| | + | rect 868 50 960 516 [[Lookup_Pattern|LKP pattern]] |
| | + | rect 366 36 441 619 [[Reference_Architecture|Reference Architecture]] |
| | + | rect 992 57 2159 587 [[Application_Services|Application Services]] |
| | + | rect 324 640 2571 697 [[Pilots|DE4A Pilots]] |
| | + | rect 651 743 1209 992 [[DE4A_Semantic_interoperability|Semantic solutions]] |
| | + | rect 1287 740 1835 989 [[DE4A Common Components|Common Components]] |
| | + | rect 1920 747 2468 992 [[Building_Blocks|Building Blocks]] |
| | | | |
| − | == Reference architecture ==
| + | desc bottom-right |
| | + | </imagemap> |
| | | | |
| − | === [[Intermediation Pattern]] ===
| + | == [[Pilots]] == |
| | + | DE4A includes three cross-border and cross-domain [[Pilots]] - [[Studying Abroad Pilot]], [[Doing Business Abroad Pilot]], and [[Moving Abroad Pilot]] -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases. |
| | | | |
| − | === [[USI|User Supported Intermediation Pattern]] ===
| + | == [[Reference Architecture|Reference Architecture]] == |
| | + | DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to projects seeking to implement cross-border once-only enabled eProcedures. |
| | | | |
| − | === [[VC|Verifiable Credential Pattern]] === | + | ==Service Interoperability Solutions Toolbox== |
| | + | The Service Interoperability Solutions Toolbox is split in Semantic Interoperability Solutions, Common Components and the library of components and BBs. The first deals with semantic specifications, the second with SW components and the last with the architecture components and candidate BBs. |
| | | | |
| − | === [[Lookup|Lookup Pattern]] === | + | ===[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]=== |
| | | | |
| − | === [[Sub notif|Subscription and Notification Pattern]] === | + | ===[[DE4A Common Components]]=== |
| | + | This section provides a functional and technical description of the common components designed and developed in the DE4A project during the '''first iteration''' in order to set up the message exchange environment. |
| | | | |
| − | == Application Services == | + | ===[[DE4A common specifications and components|DE4A common specifications and components it2]]=== |
| | + | This section provides a functional and technical description of the common components designed and developed in the DE4A project during the '''second iteration''' in order to set up the message exchange environment. |
| | | | |
| − | {| class="wikitable"
| + | ===[[Library of components and building blocks|Library of components and Building Blocks]]=== |
| − | |+ style="caption-side:top; color:#35BEF0;|''DE4A solution overview''
| + | ==Legal and ethical compliance== |
| − | |+ style="padding:10px"
| + | As an EU funded project, it is important in DE4A that legal and ethical issues are appropriately identified and addressed. For DE4A, '''legal''' compliance includes the need to ensure that the project is executed in accordance with the requirements of European data protection law (notably the General Data Protection Regulation - GDPR), and that the DE4A outputs take into consideration the EU legal framework for once-only exchanges in e-government services (notably the Single Digital Gateway Regulation - SDGR). |
| − | !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.
| |
| − | |Session 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 Component
| |
| − | |-
| |
| − | |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 Component
| |
| − | |-
| |
| − | |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 Component
| |
| − | |-
| |
| − | |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 Component
| |
| − | |-
| |
| − | |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
| |
| − | |}
| |
| | | | |
| − | == Application Components ==
| + | Complementary to the legal issues, '''ethical''' concerns need to be addressed as well. While DE4A principally aims to ensure that existing regulated e-government services can be organised digitally and in a user friendly way, there are still potential ethical challenges to be addressed, such as the right to privacy, non-discrimination, and good governance. Potential problems and mitigation measures must be identified, so that risks to European citizens can be minimised, especially in pilot activities. |
| | | | |
| | + | A specific subwiki is dedicated to the [[legal and ethical analysis]] in DE4A. On this page, you'll be able to find more information about past and ongoing activities. |
| | | | |
| − | == Applications Collaborations ==
| + | [[Category:wip]] |
| − | | |
| − | The Application Collaboration views show how different functional application components interact via interfaces in order to provide the services identified in the Business Process realization Views.
| |
| − | | |
| − | [[eProcedure portal]] | |
| − | | |
| − | [[Information desk]]
| |
| − | | |
| − | [[Evidence Interchange Management]]
| |
| − | | |
| − | [[Trust architecture]]
| |
| − | | |
| − | [[Data Logistics]]
| |
| − | | |
| − | [[Evidence portal]]
| |
| − | | |
| − | [[Evidence retrieval]]
| |
| − | | |
| − | [[Authority agent]]
| |
| − | | |
| − | [[User agent]]
| |
| − | | |
| − | == DE4A Common Components ==
| |
| − | === [[Semantic components|WP3 Semantic components]] ===
| |
| − | === [[Common components|WP5 Common components]] ===
| |
| − | | |
| − | ==[[MS Solutions]]==
| |
| − | | |
| − | == Getting started ==
| |
| − | Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.
| |
| − | | |
| − | * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
| |
| − | * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
| |
| − | * [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
| |
| − | * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
| |
| − | * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]
| |
This toolbox is the central, long-term deliverable of the DE4A Architecture work package and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA2 and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights.
The image below has clickable sections to jump to other pages like, the DE4A Reference Architecture, patterns, Semantic Solutions, Common Components and Building Blocks.
Clicking on an area in the picture causes the browser to load the appropriate wiki page.
DE4A includes three cross-border and cross-domain Pilots - Studying Abroad Pilot, Doing Business Abroad Pilot, and Moving Abroad Pilot -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to projects seeking to implement cross-border once-only enabled eProcedures.
Service Interoperability Solutions Toolbox
The Service Interoperability Solutions Toolbox is split in Semantic Interoperability Solutions, Common Components and the library of components and BBs. The first deals with semantic specifications, the second with SW components and the last with the architecture components and candidate BBs.
This section provides a functional and technical description of the common components designed and developed in the DE4A project during the first iteration in order to set up the message exchange environment.
This section provides a functional and technical description of the common components designed and developed in the DE4A project during the second iteration in order to set up the message exchange environment.
Legal and ethical compliance
As an EU funded project, it is important in DE4A that legal and ethical issues are appropriately identified and addressed. For DE4A, legal compliance includes the need to ensure that the project is executed in accordance with the requirements of European data protection law (notably the General Data Protection Regulation - GDPR), and that the DE4A outputs take into consideration the EU legal framework for once-only exchanges in e-government services (notably the Single Digital Gateway Regulation - SDGR).
Complementary to the legal issues, ethical concerns need to be addressed as well. While DE4A principally aims to ensure that existing regulated e-government services can be organised digitally and in a user friendly way, there are still potential ethical challenges to be addressed, such as the right to privacy, non-discrimination, and good governance. Potential problems and mitigation measures must be identified, so that risks to European citizens can be minimised, especially in pilot activities.
A specific subwiki is dedicated to the legal and ethical analysis in DE4A. On this page, you'll be able to find more information about past and ongoing activities.
