DE4A Common Components

DE4A WP5, Common Component Design & Development, designs and develops new common software components, required for the Pilot implementations and aligned with the other technical work packages.

Objectives include:

1. Integration and consolidation of all architectural, semantic and pilot-domain features to distil common components in order to build a fully operational environment for each piloting use case;
2. Specification of product commonalities and technical design of component interfaces fully aligned with the European Interoperability Framework and re-usable beyond the project;
3. Development of high quality and optimized common services and components;
4. Development of innovative open common components and products based on Blockchain;
5. Support to pilot and national deployments with component documentation, as well as making available the common components as new building blocks in a public repository.

Component	Description
DE4A Connector	Technical proxy that allows the final participants to send requests for evidence or responses to other final participants over an eDelivery communication environment
SSI Authority Agent	Enterprise-level solution that enables issuing and submitting diplomas in the form of verifiable credentials/presentations to Issuers/Verifiers.
SSI Edge Agent	Mobile digital wallet solution that enables users to manage their digital diplomas and interact with the Issuer's/Verifier's portals.

Common specifications

Third party specifications and components

The DE4A project is based on some specifications and components that allow building new software with some inherited capabilities such as security, reliability, integrity and scalability.

Some of the main technologies involved are described here.

Description of common software interfaces

This page contains a description of the different software interfaces created for the DE4A project. The information provided can be used as a reference on the development and integration process to each pilot.

DE4A Logs and error messages

In order to standardise the errors and logs handled by each component, some conventions have been taken, as log patterns, error codes definition or messages content.

The information on this page should be used by each partner who develops a DE4A component, also it should be maintained to have a proper messages reference and be aware which information will include.

Apart from the usual reasons of the logging and error handling, in the DE4A project, there are 3 main bullet points on which the definition of messages is based:

• Kafka tracking: messages sent to the Kafka server which can be previewed at: https://de4a-dev-pt.egovlab.eu/#!detail
• Metrics logs: messages marked with a special tag inside the common log file or logged on a separated file, which will be used to analyze and raise some metrics about each system
• Error convention: standardise the error messages and codes

Testing infrastructure

DE4A Playground

The Playground is a set of predefined and pre-deployed components to be used as is. The “DE4A Playground” was designed to help pilot partners to onboard the DE4A network. It is essentially a temporary infrastructure with two purposes:

• It simulates a real scenario where the User can request data (evidence) about a subject (citizen or company). Thus, it allows testing the performance of the DE4A Connector by using mocked components and fake data.

• It allows DE4A pilot participants to deploy their own infrastructure in an orderly manner. A three-stage process was set out for the pilot participants to deploy their software components: first their own developed entities (DE/DO), secondly the DE4A Connector, and finally the SMP of the eDelivery infrastructure. At the end of each stage, the pilot partner can test their deployment by making used of the rest of the Playground components.

DE4A Playground joining stages for the first iteration

the initial situation of the Playground for the first iteration of the DE4A project and the joining stages foreseen for the joining process of the pilot partners to the Playground. It also defines the information that each pilot partner needs to provide to WP5 in order to include that information in the appropriate components of the Playground so that the pilot partner can send messages via the Playground components.