Technical Harmonisation of UXP and X-Road Instances

The previous post addressed the legal implications of a federation of data exchange layers and introduced the Estonian-Finnish Bilateral Agreement. This last part of the blog series will take you back to State A and B and the technical issues they need to consider when federating State A’s UXP with State B’s X-Road instance.

Global Configuration

The Global Configuration is the central configuration file managed by an instance’s Governing Authority. The Global Configuration is automatically updated and shared with the members’ security servers to always have authoritative insight into current members, their security servers and (hashed) certificates, certified Timestamping, Certification Authorities, and OCSP services, as well as monitoring data. Thus, the Global Configuration needs to be shared or its content made compatible with other instances’ Global Configuration file, so that each instances’ member can have the same level of trust towards others as for themself.

Both an organisational and a technical question that certainly needs to be addressed in a federation is how long a global configuration and the OCSP responses are valid for. In the best-case scenario, they would be equal in both instances, since a difference in these could have a significant impact on the reliability of data (Freudenthal, Willemson, 2014, pg. 9).


In the UXP and X-Road federation, the certificates that verify an instance member’s authenticity are issued by accredited Certification Authorities. The certificates hold information about a unique identifier of a member and their member class. It is crucial for the federation that both the UXP and X-Road instance understand the certificates’ parameters the same way – certificate profiles need to be harmonised. However, a major difference between UXP and X-Road is that the minimal hash function for UXP is SHA-2 based, while X-Road uses deprecated SHA 11. To achieve compatibility in a federation use case, either instance would need to adjust their hashing algorithm.


All the data traffic via UXP and X-Road is encrypted. UXP gives the option to choose Elliptic Curve Cryptography in three different key lengths. X-Road uses RSA2048 in its standard set-up. Attention would need to be put on the compatibility of the encryption mechanism.

Estonian-Finnish Trust Federation Service Level Agreement

As a last glimpse into compatibility of federated secure data exchange layers, let’s take a brief look at the Service Level Agreement of the Estonian-Finnish case. It addresses the availability and validity of the key technical components, such as the Timestamping Authorities, OSCP responses, and the Global Configuration.

See PRC 2286/2401/16; RIA 16-0448-001, Service Level Agreement, pg. 3.

The discrepancy between the OSCP responses and the Global Configurations validity is particularly striking. The factors affecting this are the cost, which might certainly play a role, and the fact that when the federation agreement was concluded, X-Road was by far more established and used in Estonia. Thus, the urge by the Finnish authorities to provide the same response and validity times might have been minimal. However, in the long run, the more harmonised, the better, as this can have a significant impact on the trustworthiness and reliability of exchanged data (ibid.).


Federating UXP and X-Road technology might seem like a challenging project, but you definitely need to consider potential benefits.

Firstly, the fact that there’s a standardised way to exchange data (or “goods” for that matter) across borders. This is something we’re familiar with from the physical world – planning and building infrastructure and transportation corridors by consortia consisting of multiple states, so that goods can safely and reliably cross borders. Most certainly a fascinating promise and driver for innovation.

Secondly, imagine how much resources could be saved, if data would only need to be entered once for it to be accessed by a different jurisdiction on a need-to-know basis. Moreover, what would it be like, if different jurisdictions could share the burden of administrating data? While that would be a challenge to current understanding of nation states, it certainly allows for a more integrated way of administrating societies in a globalised world.

Thirdly, data exchange infrastructure wouldn’t only be federated for the benefit of the public sector – it would allow businesses and citizens to innovate and build digital services on top of it.

Are you the first state or corporate consortium to federate UXP/X-Road instances? Please reach out to find out more or read about the concept of secure data exchange.

Written by Tobias Koch

1 Barker, Elaine (May 2020). “Recommendation for Key Management: Part 1 – General, Table 3”. NIST, Technical Report: 56.

Willemson, J., Ansper, A.: A Secure and Scalable Infrastructure for Inter-Organizational Data Exchange and eGovernment Applications. In: 2008 Third International Conference on Availability, Reliability and Security. pp. 572-577

Freudenthal, M., Willemson, J.: Challenges of Federating National Data Access Infrastructures. In: 2017 International Conference for Information Technology and Communications. Springer, Cham.

PRC 2286/2401/16; RIA 16-0448-001: TRUST FEDERATION OF ESTONIAN X-TEE AND FINNISH PALVELUVÄYLÄ, General Agreement between Estonian Information System Authority and Finnish Population Register Centre, 2016.