1.2. Functioning of X-Road in the view of dataservice developer

As data exchange takes place on X-Road through dataservices (web services), one member is always the provider of the dataservice and the other the user of the dataservice.

In order to achieve secure data exchange, each member must pass the following stages:

  • affiliation of membership;
  • description of dataservices and granting access rights;
  • data exchange;
  • long-term validation of transaction.

Steps of each stage are described in detail below.

1.2.1 Affiliation of membership

  1. A member (organisation) obtains necessary certificates (for mutual authentication of security servers and e-stamping of messages by members) and trust services, including OCSP service ensuring sufficiently recent validation of certificate.
  2. Binding the certificate with X-Road via a security server and registration of the information system in X-Road Center.
  3. Obtaining a timestamp service.

Parties in affiliation of membership are shown on Figure 2.


Figure 2 Parties in affiliation of membership

1.2.2 Description of dataservices and granting access rights

Description of dataservice:

a) the provider of dataservice develops and describes X-Road dataservice for provision;

b) the user of the dataservice develops the required customer application for the dataservice.

Granting access rights:

a) the user of the dataservice asks the access right for the necessary dataservice;

b) the provider of the dataservice grants access rights to other members for using the dataservice.

Parties for the description of dataservices and granting access rights are shown on Figure 3.


Figure 3 Parties for the description of dataservices and granting access rights

1.2.3 Data exchange

  1. The user of dataservice drafts a SOAP message in the subsystem of their information system (the part of information system of an authority which is registered on X-Road is called a subsystem), and it is signed in the security server of the user (digitally stamped), using OCSP validation.
  2. A temporary bilaterally authenticated encrypted (TLS) channel is created between the security servers of the user and the provider of dataservice via public internet. Through this channel, the user of the dataservice transmits parts of the message as MIME elements, including a SOAP message.
  3. The security server of the provider of the dataservice checks the signature of the message (e-stamp) and adds the body of the SOAP message into the message log, which is timestamped after specified interval. Then, the provider of the dataservice forwards the message to their information system for processing.
  4. The interface component of the authority providing dataservice converts a SOAP request received from X-Road into the form enabling the information system of the authority to process it. The response received from the information system is also converted by the interface component into a form suitable for X-Road (as a SOAP response).
  5. The response is signed in the security server of the provider and returned to the user of the dataservice via a temporary channel.
  6. The encrypted channel is closed after sending the response. (Actually, the encrypted channel is buffered and it can be used in the following requests to the same member, but this fact is not important for the developer).
  7. The security server of the user of the dataservice verifies the signature of the response (e-stamp) and transmits the received data to their information system for processing.

Parties of data exchange are shown on Figure 4.


Figure 4 Parties of data exchange

Figure 5 illustrates the operation of X-Road from the developer’s perspective and the used technologies. The borders of organisations are shown with a dashed line. In X-Road Version 6, members are not differentiated in terms of use and the provision of dataservices. The interface component and MISP communicate with security servers, using the SOAP protocol. Security servers transmit messages as MIME parts via a bilaterally authenticated encrypted channel.


Figure 5 Operation of X-Road from the developer’s perspective and the used technologies

1.2.4 Long-term validation of transaction

  1. After reasonable time (30 times a day), each party timestamps the received messages to ensure a long-term integrity warranty. Timestamp is fixed to requests as well as to responses in each security server.
  2. Security servers of members report meta-information of the use of services requested by the central monitoring component to X-Road Center.

Parties to the long-term validation of a transaction are shown on Figure 6.


Figure 6 Parties to the long-term validation of a transaction





Viimati muudetud: teisipäev, 16. mai 2017, 10.17