DE4A Playground joining stages for the first iteration

From DE4A
Revision as of 16:38, 22 February 2022 by Antonio.osuna (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

DE4A Playground: initial stage

The DE4A Playground is the main element of the DE4A testing infrastructure. It simulates a real scenario where the User can request data (evidence) about a subject (citizen or company).

At its current development status, the Playground supports the complete message exchange process based on the Intermediation (IM) and User-Supported Intermediation (USI) patterns.

The following diagram depicts the initial deployment status of the Playground:

Schema of the initial scenario of the Playground
Schema of the initial scenario of the Playground

Description of the components:

  • Mocked DE. It simulates the role of a Data Evaluator (DE). It is composed of a Web page to send IAL lookup messages to the mocked IDK and evidence request messages to the UM Data Requestor (DR) and to display the responses. It also implements the software interface of a DE to receive responses from the University of Maribor Data Requestor when the communication is based on the USI pattern. It is also able to redirect the User to the preview portal of the corresponding DO when using the USI pattern. It is deployed on UM premises (Slovenia).
  • University of Maribor Data Requestor. Latest version of the DE4A Connector, taking the role of a DR. As an AS4 Gateway, it uses the phase4 gateway integrated in it. It is deployed on UM premises (Slovenia).
  • SML/DNS. External component provided the Commission, part of the eDelivery infrastructure. It allows discovering the SMP of a DE4A final participant (DE or DO).
  • SGAD SMP. Component of the eDelivery infrastructure that allows discovering the routing information of a DE4A final participant (DE or DO). To do so, it is populated with the routing information of the fake partners of the examples stored in the mocked DO. There is only one SMP deployed, which is shared by SGAD. It is deployed on SGAD premises (Spain).
  • Mocked IDK. REST service that implements the Issuing Authority Locator (IAL) API defined by WP3 [1]. It is populated with the generic information of the real and fake pilot participants required for the IAL functionality to work. It is deployed on UM premises (Slovenia).
  • SGAD Domibus. European Commission’s reference AS4 Gateway, deployed in SGAD premises (Spain).
  • Mocked DO. It simulates the role of a Data Owner. It implements the software interface of a DO to receive evidence request messages from the SGAD Data Transferor and to send back the responses. It handles a database consisting of testing datasets [2] made up of examples of canonical evidences of each pilot and each canonical evidence type. It also implements a user interface to preview evidences and to accept or reject them when the communication is based on the USI pattern. It is deployed on SGAD premises (Spain).

In order to differentiate between pilot partners who has already deployed their own final participants and the fake participants of the mocked DO, the latter use “9999” as a schema.

When a pilot partner properly connects a final participant (DE or DO) to the Playground, it will be able to immediately send evidence request messages to the mocked DO and receive evidence response messages from it, in case it is a DE. In case the deployed final participant is a DO, it will be able to receive evidence request messages from the mocked DE and send evidence response messages to it.

As soon as another final participant successfully joins the Playground, both pilot partners will be able to exchange messages between their final participants (provided that one of them is a DE and the other a DO).

Playground joining stages

Each pilot partner needs to deploy their own infrastructure step by step and connect it to the Playground in order to join the piloting phase of the project.

The following sections describe different foreseen stages of the first iteration of the project through which pilot partners can walk their way to have a complete infrastructure ready for the piloting phase according to the DE4A conceptual schema. It is not mandatory that every partner goes through all stages and in that specific order, but it is recommended as it establishes a logical deployment path.

DE4A conceptual schema for the first iteration
DE4A conceptual schema for the first iteration

Once a pilot partner has properly joined its final participant (DE/DO) to the Playground, it can exchange messages with either another pilot partner, with the mocked DE or with one of the faked final participants of the mocked DO.

It should be noted that in the following schemas of joining stages, eIDAS nodes have been omitted for the sake of simplicity, although it is necessary that each partner deploys its own eIDAS node and integrates it with the corresponding software entity (DE or DO, depending on the participant’s role).

It is also worth noting that the joining stages bellow are only intended for the IM and USI patterns. At the moment, the rest of the patterns (“Verifiable Credentials”, “Lookup” and “Subscription and notification” patterns) are not supported by the Playground.

Joining stage 1: DE/DO

In this first stage, pilot partners have their own DE4A final participant (DE or DO) deployed. Using only this component, they are able to exchange messages with either another pilot partner or with one of the faked participants of the mocked DO.

Joining stage 1: DE/DO
Joining stage 1: DE/DO

Components deployed on the pilot partner side:

  • Final participants (DE or DO). The pilot partner must develop and deploy its DE4A final participant, which is a DE or a DO or both, depending on their role in the project. To successfully develop a final participant, the DE4A document “DE4A D5.3 Initial technical design of interfaces” defines the DE4A Connector software interfaces, the software interfaces to be provided by a DE or a DO and the common specifications that must be met.

Configuration on the pilot partner side to join the Playground:

  • The deployed final participant must be configured to communicate with the interface of the corresponding DE4A Connector of the Playground (whose endpoint URLs can be found above):
    • If DE → to the UM DR
    • If DO → to the SGAD DT

Pilot partner data required to join the Playground:

  • URL of the DO interface endpoint to be included in the SGAD DT, so that it knows where to forward the messages sent to the partner DO.
  • URL of the DE interface endpoint to be included in the UM DR, so that it knows where to forward the messages sent to the partner DE. Only for DEs using the USI pattern.
  • URL for the User redirection to the preview portal of the DO, to be stored in the mocked IDK. Only for DOs using the USI pattern.
  • URL of the host of the DE e-procedure portal where the User is redirected back from the DO, in order to include it in the whitelist of outgoing communications of the SGAD. Only for DEs using the USI pattern.
  • The necessary routing information about the final participant to feed the SGAD SMP:
    • Per final participant (DE/DO)
      • The DE4A role (that is, Data Evaluator o Data Owner).
      • The URN format participant ID
        • i.e. “iso6523-actorid-upis::9920:ess2833002e”
      • The URN format ID of the canonical evidence types it may request or provide.
        • i.e. “urn:eu-de4a:identifiers:CanonicalEvidenceType::BirthEvidence”
    • In the SGAD SMP, this data shall be linked to the DE4A Connectors deployed in the Playground or to its AS4 Gateways.

The identifiers of participants and canonical evidence types, among other useful related information, can be found in the Excel document “DE4A-exchange-participation-and-provision-data”.

Joining stage 2: DE/DO and Connector

In this second stage, pilot partners have their own DE4A final participant (DE or DO) and DE4A Connector (DR or DT) deployed.

Joining stage 2: DE/DO and Connector
Joining stage 2: DE/DO and Connector

The pilot partner has developed and deployed its DE4A final participant (DE or DO) and its own DE4A Connector with the corresponding role: DR if the partner is a Data Consumer or DT if the partner is a Data Provider. To properly set up the DE4A Connector, an AS4 Gateway must be set up too, either the phase4 integrated in it, or another external AS4 Gateway such as Domibus.

To join the Playground, the DE4A Connector must be properly configured to send messages to Commission’s SML/DNS, the mocked IDK and the SAGD Kafka server.

In addition to the components of the first stage, the components deployed on the pilot partner side are:

  • DE4A Connectors (DR or DT). The pilot partner must deploy its own DE4A Connector with the corresponding role:
    • DR if the partner is a Data Consumer and has also deployed a DE.
    • DT if the partner is a Data Provider and has also deployed a DO.

In case a pilot partner has both Data Consumer and Data Provider roles, it must deploy a DE connected to a DR, and a DO connected to a DT (that is, two DE4A Connectors with different roles).

  • The DE4A Connector has its own AS4 Gateway integrated within it. However, if the pilot partner wishes to use an external AS4 Gateway, such as Domibus, it must deploy it separately.

Configuration on the pilot partner side to join the Playground:

  • The deployed final participant must be configured to communicate with the interface of the corresponding DE4A Connector of the same pilot partner.
  • In case of being a DR, the DE4A Connector must be configured to look up on its own the necessary routing information of the recipient DO from mocked IDK. In any case, the DE4A Connector must be configured to exchange messages with the Commission’s SML/DNS and other SMPs, and to send messages to the SGAD Kafka server as well. To do so, two guides are provided: “DE4A D5.5 First Release of DE4A Common Components” and the “Readme installation guide”.

Pilot partner data required to join the Playground:

  • URL of the host of the DE e-procedure portal where the User is redirected back from the DO, in order to include it in the whitelist of outgoing communications of the SGAD. Only for DEs using the USI pattern.
  • The necessary routing information about the final participant to feed the SGAD SMP:
    • Per final participant (DE/DO) and canonical evidence type (requested or provided):
      • The DE4A role (that is, Data Evaluator o Data Owner).
      • The URN format participant ID.
        • i.e. “iso6523-actorid-upis::9920:ess2833002e”
      • The URN format ID of the canonical evidence types.
        • i.e. “urn:eu-de4a:CanonicalEvidenceType::BirthEvidence”
      • The endpoint URL of the deployed AS4 Gateway (or of the DE4A Connector when using phase4).
      • The X.509 eDelivery certificate of the private key set in the deployed AS4 Gateway (or of the DE4A Connector when using phase4).

For example, pilot partner A has deployed a DE1 and a DR1 with a Domibus as its AS4 Gateway, and it will request the “Proof of Completion of Higher Education” as canonical evidence type. In addition, it has also deployed a DO1 and a DT1 with a phase4 as its AS4 Gateway, and will provide the “Proof of Birth” and “Proof of Marriage” as canonical evidence types. Then, it needs to provide to WP5 the following information (to be included in the SGAD SMP):

  • For DE1 and HigherEducationDiploma:
    • The role: DE.
    • The participant ID of the DE1.
    • The canonical evidence type ID:
      • urn:eu-de4a:CanonicalEvidenceType::HigherEducationDiploma
    • The endpoint URL of the Domibus instance.
    • The X.509 eDelivery certificate of the Domibus instance.
  • For DO1 and BirthEvidence:
    • The role: DO.
    • The participant ID of the DO1.
    • The canonical evidence type ID:
      • urn:eu-de4a:CanonicalEvidenceType::BirthEvidence
    • The endpoint URL of the DT1.
    • The X.509 eDelivery certificate of the DT1.
  • For DO1 and MarriageEvidence:
    • The role: DO.
    • The participant ID of the DO1.
    • The canonical evidence type ID:
      • urn:eu-de4a:CanonicalEvidenceType::MarriageEvidence
    • The endpoint URL of the DT1.
    • The X.509 eDelivery certificate of the DT1.

Regarding eDelivery certificates, self-signed certificates will be used for the preproduction environment. The instructions for requesting them can be found in the document “DE4A Request for Pilot Certificates”. For the eventual production environment, real and valid eDelivery certificates will be needed, for which another WP5 guidance document will be published.

Joining stage 3: DE/DO, Connector and SMP

In this final third stage, pilot partners have their own DE4A final participant (DE or DO), their own DE4A Connector (DR or DT) and their own SMP deployed.

Joining stage 3: DE/DO, Connector and SMP
Joining stage 3: DE/DO, Connector and SMP

In addition to the components of the second stage, the components deployed on the pilot partner side are:

  • eDelivery SMP. The pilot partner must deploy its own SMP, so that final participants will query this SMP instead of the SGAD SMP to retrieve the routing information of the AS4 Gateway.

WP5 has published a document on the installation and configuration of an SMP. Document “eDelivery usage in DE4A” offers further information on the use of the eDelivery infrastructure in DE4A.

Regarding the pilot partner data required to join the Playground, compared to joining stage 2, it is expected that the SMP entries will be migrated from the SGAD SMP server to the pilot partners’ SMP servers. This must be an aligned action between SGAD and the pilot partners. This means that, when a pilot partner has deployed its own SMP, it should get in contact with WP5 to begin the process of moving the corresponding information from the SGAD SMP to the pilot partner’s one.

Retrieved from ‘https://wiki.de4a.eu/index.php?title=DE4A_Playground_joining_stages_for_the_first_iteration&oldid=4541’