Collaborating across borders: Lessons from NIIS and the X-Road journey

In this talk, Petri Kimaki, CTO of the Nordic Institute for Interoperability Solutions, discusses the organization's mission to develop digital government solutions through collaboration, particularly focusing on their main product, XRO. NIS was established in 2017 by the governments of Estonia and Finland to enhance interoperability and secure data exchange. XRO, initially developed in Estonia and later implemented in Finland, serves as an open-source solution for secure data exchange, facilitating national-level interoperability. The speaker elaborates on the challenges faced during its development, the roles of various stakeholders, and the governance model. Furthermore, he outlines future plans to enhance XRO's interoperability with other data exchange ecosystems by implementing a standard data space protocol stack, thus evolving into a more integrated solution for secure data handling across organizations.

Hello everyone. My name is Petri Kimaki and I'm the CTO of Nordic Institute for Interoperability Solutions, NIS for short. Uh so uh today I'm going to tell you uh a little bit about uh NIS and XRO which is our main product. uh but let's start with the uh Nordic Institute for Interoperability Solutions. So, NIS is a nonprofit association which mission is to develop digital government solutions to

its members. Uh currently uh all in all we have uh eight members uh and we have three different membership levels but a little bit uh more about the levels later. So uh today we have um eight members uh but when NIS was established in 2017 uh initially uh we we had two members and NIS was established uh by the governments of Estonia and Finland and over the

years uh we've uh got more uh more like uh slowly and steadily uh rather like uh getting a big big peak at once. Uh but then uh why uh NIS was originally established and and what's kind of the uh well uh behind the main mission and what what makes NIS a little bit special. So first of all uh NIS is an uh nonprofit association uh originally established

by by two uh governments and originally uh the aim was to collaborate in the field of interoperability and and data exchange and always to uh save resources by joint development of of digital uh government solutions. And uh well on a more practical level uh everything uh got started around our main product XRO. So XRO is an open-source solution for secure data exchange. I will tell more about

XRO later. Uh it was originally developed in Estonia already uh 25 years ago. uh at and then uh in 2014, 2013, 2014 also Finland uh started to implement it. And uh originally uh the idea in Finland was to just uh implement it as an offthe-shelf product. No development, just uh install it, configure it and and so on. However, things didn't go uh quite as planned and some

uh additional development was needed and and by the way, back then X-RO wasn't uh an open-source solution yet. So uh it led to a situation where uh both Estonia and Finland were developing uh the X-RO uh software uh together and of course in that kind of a situation there is a risk that if you don't coordinate the development activities in any ways then there is a really

big risk that uh the two versions they become uh non-interoperable with each other and and actually you have to two separate forks and this situation was something that Finland and Estonia wanted to avoid from the beginning and um because of that uh some coordination of the development activities was uh was uh required and uh it was done uh done by the public authorities who were responsible of

the of the uh x-road deployments in in Estonia and Finland. and the digital agencies of of both countries. Uh and yeah uh during those years basically uh XRO was developed by together by Estonia and Finland but both countries they had their own development uh own management model uh source code repositories backlogs uh development teams everything everything was basically duplicated uh which wasn't very very effective indeed and

And also it created some uh challenges uh to the development as self uh because both countries they had their own uh release cycle and uh the way how the source code was managed and synchronized. It it wasn't like true open-source development development in a one shared open-source repository, but both had their private repositories that were synchronized regularly and then uh also regularly uh starting from a certain

point uh the code was was published but but yeah not not like real open source development. So uh quite many challenges but still uh they made it work in a sense that uh no no two different forks of of X-road were born. uh but still uh during that time uh the idea was born that hey probably uh it it would be possible to do this thing a

little bit more efficiently and uh since Estonia and Finland they are neighboring countries both are digitally quite advanced uh in the future there might be other uh opportunities for for collaboration as well so instead of doing this thing separately uh why not consider establishing a joint organization that could take over the development activities and make everything more efficient. And that's kind of the idea uh original idea

behind NIS and why NIS was was and and then uh NI uh well it was established officially in 2017 it be became operational in 2018. By the way, I joined NIS uh in 2018. So I've been with them uh since then uh over 80 years already. And uh then in 2018 uh MI took over all the development responsibilities from uh Estonian and Finnish digital agencies and started

to uh started to make the development work for them. And of course in in collaboration uh with them and uh today uh besides XRO which is our main product we also have another uh opensource product harmony e delivery access. Uh they are both products for secure data exchange between organizations with the difference that XRO is is mainly uh used for national level data exchange while harmony delivery

access is for uh data exchange crossber data exchange between the EU member states. So when it comes to NIS responsibilities regarding these products uh you can consider NIS basically as the software vendor of these products. Uh but uh they are open source. So we are not actually selling anything. But if you consider the the responsibilities we are managing uh developing verifying and auditing the source code. Uh

we are managing the documentation. We are uh managing the requirements, handling the backlog and and conducting development and our operational model work so that our goal is to keep our own uh organization very small and agile. Currently we are just seven people working uh directly for NIS and then uh we use outsourced uh partners when it comes to uh development activities. So currently we have eight developers

working in our development team and they are all all external uh consultants. So we basically do uh public pro procurements regularly and and in that way choose uh the companies who are collaborating with us. Uh and then of course besides the uh development and management activities we also do all kinds of international collaboration. Uh however one thing that we do not do is uh operate uh the

software that we develop. So we only develop the software and then uh the users of the software they are responsible for deploying it uh configuring it, operating it and and so on. Uh so we are concentrating only only on the development. Uh so from that perspective uh the responsibilities they are kind of clear. Uh but of course that kind of uh share of responsibilities it it also

creates some challenges. For example uh we are not very well aware of who are using our software because it's open source. It can be used free of charge without registration. But uh this is the challenge of all the open-source software more or less it it w would be nice to find some some common solution to it. But then when it comes to the knees governance model uh

this is how it looks like. So uh general meeting is the uh highest uh decision making body of knees. Uh so earlier I mentioned that we have three membership levels. we have strategic members uh contributing me members and then associate members. So uh the strategic members uh they are uh allowed to participate in the decision making uh on the niche level. So uh the strategic members they

have representatives in the general meeting and the general meeting has full decision making power regarding everything related to NIS. So for example uh they define and approve our strategy uh that defines that we as an organization are are doing. Uh then there is the advisory group uh that's kind of relaying information between the general meeting and the management board. Uh advisory group doesn't have any any decision

making power. It's more like a supportive uh supportive entity. uh but then uh that was the n uh operational model or or management model but then we of course have a separate uh management model for our products. So uh for every product we have a steering committee and for most of the products we also have a technical committee and uh the strategic members they are allowed to

participate in product uh steering committees and technical committees and then also contributing members they are allowed to uh participate in in these committees as well. uh and when it comes to decision making. So uh the product steering committee it approves the product strategy and budget uh meaning that uh the uh strategic members and contributing members uh they are allowed to participate in in this the decision making

on on the product level. uh then the technical committee instead they prioritize product backlog and they approve technical decisions and associate members they are allowed to participate in the technical committee uh but only in in a listener role. So when it comes to decision making uh where either on the product strategy level or or on the technical level it's limited to strategic members and contributing members and

associate members. They are allowed to participate and and uh well listen and of course participate to discussions and and so on. But but when it comes to decision- making they have no decision- making rights. And just to give a uh clearer uh picture uh regarding the responsibilities of these different committees steering committee and technical committee. So for example if there is a whole new feature that is

needed for X roles that requires development work budget and so on uh it must be approved by the steering committee first. Then we start working on the implementation and then uh later during during the implementation we need to make decisions regarding uh technical details how some specific detail uh of the feature will be implemented. Then we discuss those details with the technical committee and they approve our

changes. So, so that's that's how it goes. And in general, I have to say that over the years, well, now we've been doing this for for eight years. Uh, and uh we have three members who are allowed to participate in decision making on the product level. Uh well, when there are decisions uh we we vote and uh as as so far uh everything has worked really really

well. So even if you could imagine that well even with three organizations it's it's easy to find yourself in a situation where where they absolutely do not agree with something. uh fortunately we we haven't been in in a such a situation yet. So even if uh maybe uh not always there is a full there isn't full alignment between the members uh but kind of the uh spirit

is very good and uh different members are are ready to listen uh the needs of the others and and be flexible and then it it works uh might work the other way around next time. So overall uh this this model uh has worked for us really But then uh besides uh product development we also have other strategic focus areas. Uh continuous services and support is a pretty

new one. We are currently working on it. So uh we are uh going to provide uh uh support custom development and uh maybe also hosting services to our members. So the idea is that these continuous services and support we are not providing them just to anyone who who is who is asking them but specifically to our members. try to provide additional benefits to our members for more

bang for their buck uh as as to say. Then uh we are also uh actively doing research projects. Uh we usually work so that we collaborate with external research organizations and and universities. For example, last year we had a research project about postquantum encryption and secure processing environments. Uh this year we are going to look into uh the role of AI agents in in data spaces. Uh

and in general we do a couple of research projects in in uh in a year. Then we are also pretty active in international cooperation. So Anise is a member of several uh international associations for example GA X uh the international data spaces association and of course the Eclipse Foundation. Uh so yeah pretty important area of of what we are doing and then of course uh we are

also uh doing organizational development all the time and sustainability is is also a very important value to us in general. Uh we try to develop knees as an organization all the time and definitely this is not a closed club. we are actively looking for new member organizations and and also new new products. So uh if if an organization is uh interested in in joining n they maybe

have a new uh product they would like to bring with them. Uh that's that's also possible. So we can expand uh both our our members range and and also our our product uh selection. But then uh a little little bit more about uh XRO. So uh like mentioned uh it's an open-source uh product license standard MIT opensource license. So it's a decentralized solution for secure data exchange

between organizations. Uh it's one of the most deployed digital public infrastructure components worldwide and it's also a digital public good verified by the digital public good alliance and it was uh originally developed already uh in in 2001 in Estonia. So it's definitely not a new solution. Uh but um in order to uh in order uh for it to get more popular globally, it it took sever several

years. And one reason for that is without a doubt that it wasn't open sourced until 2015. So until then it was a closed source solution and after that uh it's been available under the MIT license and yeah that's kind of when when it really started to take off and uh today there are at least uh 29 uh countries using XRO worldwide and there are almost 600 million

people living in the countries which means six almost 600 million potential end users. Uh in the X-RO community uh we have uh almost 170 countries and over 5,000 members. So you can really say that XRO is is truly a global solution today. And here you can see uh on the world map the countries where XRO is currently being used. As you can see, uh, it it has

a very, uh, wide user base in in Latin America and it it's still growing. Also, Africa is is growing pretty rapidly. And, uh, the good news is that we are also seeing a lot of interest in in Europe lately. This uh diagram uh illustrates an X-RO ecosystem and and what kind of uh member organizations it it it typically has. So uh one uh interesting different between XRO

and many other data exchange solutions is that uh typically uh data exchange ecosystems they are built around some specific uh business domain for example finance, healthcare, transportation or so on. Uh but uh with XRO uh things usually work a little bit differently. Uh the most uh typical deployment model for XRO is a national deployment meaning that a country uses XRO to deploy a national data exchange infrastructure

that is available to all kinds of uh different organizations. So typically uh the the national ecosystem it's it's owned and led by the public sector uh but it's still open for all kinds of organizations to join and exchange data and that's the case also for example in Estonia and in Finland and this diagram uh the the organizations types of organizations that you can see in this diagram

they are taken from the real Estonian ecosystem so in the Estonian extro ecosystem system. All these different types of organizations exist together and exchange data with each other. And uh uh one uh more thing to mention uh that kind of enables this kind of approach is that XRO is fully data type and semantic agnostic. So you can exchange any kind of data with XRO. XRO guarantees uh

the security of the data exchange but it it doesn't care what kind of data you exchange can be JSON XML binary encrypted uh non- enrypted what whatever so uh the best way to understand how XRO works is to compare it to traditional pointto-point integrations so when you use point-to-point integrations all the details of the data exchange, they need to be agreed separately for every connection. And well,

it may work actually pretty well if you have only few information systems and not too many connections between them. But as soon as the number of information systems and connection starts to grow, it it can become quite challenging. And also if you want to enforce some specific policies like security policies for example then yeah it might be a little bit different uh with point-to-point integrations. uh XRO

results uh this approach uh by using the four corner model which idea is that uh information systems are not connected directly uh but instead through unified access points and all the data exchange takes place through them. In the XRO architecture, the access points are are called security servers. And like you can see in this diagram, every organization has its own security server. They connect their information systems

to it. And then all uh the data exchange happens through the security servers that guarantee that it's uh secure uh unified and and also traceable. This diagram of course is a simplification. In a real uh XRO ecosystem, you have a lot more and uh the setup is is usually a lot more complex. Meaning that organizations they can have more than one security server uh or security server

cluster or alternatively uh more multiple organizations can share uh the same security server which is a common approach for for small So uh in general XRO is is based on a decentralized uh architecture uh but with centralized management and in in practice it means that all the data exchange take takes always placed directly between the service consumer and service provider. There's uh no third parties, no message

brokers or or anything between the service consumer and service provider. No one else can see what kind of data they are exchanging. However, uh there are some central components. Uh the central server is is a key component in the X-RO architecture. It's kind of the member registry or phone book of the ecosystem. uh when new organizations join uh they are registered to the central server. So the

member organization and their security server they are both registered there and then uh the central server is is publishing the member registry uh making it available for the security servers to see uh who are the members of the ecosystem. So when data is being exchanged that information is is used to verify the the counterparty of the data exchange and the verification process works so that it doesn't

require uh the central server to be available 24/7. uh so in in practice uh the ecosystem can be configured so that the central server can be unavailable even for days uh without it affecting the data exchange. So uh usually the first counterargument uh uh regarding this architecture is that hey uh the central server is a single point of failure. Well, yes, in theory it is, but in

practice it can be configured so that it it it's really not. Uh, one key feature of X-RO is federation, which means connecting uh two X-road ecosystems uh to one another and once the ecosystems have been connected uh then the member organizations can exchange data with each other as if they were members of the same X-RO ecosystem. And setting up the federation is technically very easy. Requires uploading

a couple of configuration files. Uh takes like 10 15 minutes if you know what you're doing. Uh so technically uh quite straightforward. Uh but then uh there is also an administrative side of things. So you need to have a fed federation agreement between the two ecosystems and and their operators and of course a data exchange agreement between the member And often uh these uh administrative processes they

may take a lot longer time compared to the technical stuff. Uh well another interesting piece of information is that XRO uh is an enabler for the once only principle. So the once only principle means uh basically that citizens and uh organizations they should only provide their information uh to the public sector once and then if uh multiple public authorities need access uh to the same uh information

instead of asking it again they should share it with each other. So XRO is a technical enabler uh for that and uh it's used uh for that those purposes on a national level. Uh but then there is also the uh EU level once only technical system that's meant for exchanging uh uh evidence. So basically uh different types of documents between the EU member states and uh the

EU uh once only technical system it's it's based on a different technology it's it's not using XRO it's it's using e delivery for for data exchange and um one uh question that we often hear is that hey uh is it a problem if on a national level we are using XRO but then we need to connect to the EU1's only technical system that uses e delivery. Is

it a problem? Can it be done? So the good news is that it it can definitely be done. Uh Estonia and Finland, they are already doing it. uh they have implemented uh kind of a well you could call it a connector or or an adapter uh that sits between the uh national X-road ecosystem and the once only uh technical system and in practice it means that um

it's possible to use the uh same interfaces uh and integrations that are already used on a national level. you can use them also on on the EU level. So you don't need to uh build uh separate interfaces, separate integrations for them. Uh so yeah uh and and in this diagram the the adapter or or gateway it it would basically be this woods uh component and uh yeah

uh this is on on a high level this is how it works and and both Estonia and Finland are are already doing it. So it it definitely can be and uh in addition to the uh X-RO community that I mentioned earlier. Uh so we we also have X-RO technology partners uh that are companies that provide X-road related uh support and services. So of course NIS uh provides

online resources for example we have free online training platform XRO AC Academy where you can find free online online trainings uh we have documentations then there is the uh there is the X-road community where you can look for help but in in case if if you need uh uh need uh more let's say help on a wider scale uh consultation services, hosting, uh, help with extra deployment,

then there are several companies that provide those services and not only in Europe, but but also in in other parts of the world and the number is increasing all the time. Then uh, next a couple of words about the future about the X-RO8 uh, spaceship. Uh we are currently implementing some pretty big changes in X-RO. Today XRO uh provides interoperability between uh two X-road ecosystems and within

one XRO ecosystem. Uh but it's a challenge if you need to exchange data with with uh data exchange ecosystems that use other technologies. And uh we can see that uh the need for organizations to exchange data and be member of uh different ecosystems is increasing all the time. And therefore we want to make XRO more interoperable with with other data exchange ecosystems as well. And uh uh

the path that we have chosen uh to make it happen is to uh transform XRO into a databas. So basically we are going to replace XRO's uh current custom protocol stack with the uh standard data space protocol stack which uh enables XRO to be interoperable with other data exchange ecosystems and data spaces that use the same set of standards and and specifications. So uh the high level

vision for XRO 8 is to transform XRO into a data space solution. Uh but of course uh since XRO already has a well lot of legacy in a good sense uh behind it. We want to keep all the good that it already has and only get rid of the bad and the ugly. So we want to give the proven ecosystem model and and security and then improve

the interoperability uh by implementing the data space uh protocol stack. Of course a big challenge in that is is backwards compatibility because we need to take the existing users into account. Can't start everything from scratch. And in our case the data space protocol stack in practice means uh implementing support for the data space protocol and decentralized claims protocol. So the uh data space protocol stack can be

divided roughly into three layers uh trust plane, control plane and data plane. And the idea is that the trust plane and control plane they are standardized different uh data spaces should use the same specifications and standards on those layers and then uh the data plane level where the actual data exchange takes place it's it's more like data space specific. So uh so yeah uh this is uh

on a high level how how it looks like and uh when it comes to the uh timeline uh XRO 8 is uh scheduled to be released uh by the end of this this year. So uh so yeah uh happening pretty soon. Then I also wanted to say a few words about the Eclipse data space working group. Uh so NIS is a strategic member of the working group

and since we are using the data space uh standards and instead of just uh using them and and following them we felt that it's it's really important to be involved in in their development. So the data space protocol, decentralized claims protocol and data plane signaling protocol they are all under the purview of the Xlips data space working group and that's why it's it's uh important for us

to be involved and then we also utilize existing open source components uh in the implementation. We don't want to implement the protocols by ourselves and one of the key component is the Eclipse data space components EDC. Uh so so yeah uh we feel that it's uh important to be in involved uh in the group because it's it's working uh with uh with with the EDC and the

specifications that are play a key role when it comes to the X-RO's future. And then finally uh some uh lessons learned uh well regarding knees and and also regarding x road. So first uh ensure uh strong political support and long-term alignment. uh this is valid for both NIS as an organization and and also also for XRO as a as a software product or actually for any digital

service that you want to implement uh nationally. So with without political support it's it's really different to get get forward and and get long-term support for your initiative. then engage the right stakeholders at the right time. Well, sign sounds kind of obvious but what I mean by this is that you saw that we have many different kind of groups and committees general meeting advisory group uh product

steering committee product technical committee. Uh so it's really important that uh we get the right people in those groups. So people who are interested in the specific topic and also who have the power uh to make decisions regarding those things in in their own countries and and organizations uh because otherwise uh things things don't move. Uh we are not able to uh make the decisions that that

we need. Uh so it may sound obvious but it in in real life it it can actually be quite quite challenging but then in the best case when you get the right people then things uh things should move and work pretty pretty uh pretty nicely. Then um adopt fitforpurpose operational models. Well, this also sounds kind of obvious and what I mean by this is that well once

again these different working groups and committees uh well you can organize them in in many different ways and for example NIS is a member of many international associations that have working groups and they they all have a little bit different kind of ways of working. For example, in some cases, the uh participants of the groups they need to uh kind of uh facilitate well not facilitate but

uh uh provide uh their uh time and availability to to work on on different things uh that are in the group's agenda. or alternatively uh the organization who's facilitating the groups may do the actual work and then uh present the results and and the participants they can only vote and and uh kind of uh steer uh the group. So, uh, I don't know. Uh, in my opinion,

there probably isn't one right way to do it, but you should always consider what's what's a kind of the best approach for your particular case. Then, uh, prioritize active engagement over community size. Uh well uh I mentioned that NIS has over 5,000 uh community members but we the amount of uh committers for XRO from from the community it can be counted in tens not hundreds or or

in thousands h and um yeah mean meaning that um it's it's a challenge to get active contributions and uh yeah if if you happen to find uh community members that are interested in the project, want to be active. Yeah, it's it's really good to uh support them and and uh facilitate that kind of I'm a software engineer um uh and for me while uh resolving technical issues,

it's well technical issues they they can always be resolved in in one way or another. uh but quite often in this kind of context uh where NIS operates we also have a non-technical issues like administrative or or legal topics uh so resolving them it's it's better to reserve uh time for them usually it it's a little bit slower and yeah then last but not least keep legislation

and policies technology neutral uh I have one very good example about this what you shouldn't do. So in uh several niche member countries there are uh national laws uh that are about using X-road at the national level. Uh those laws include names of X-RO components and now uh as a part of making XRO data space technology we want to uh change the names of the components and

yeah since they the names are included in the uh laws of some of the member countries. We need to figure out hey can can we do it? Do the laws also need to be changed and and and how does that work? So better to keep them technology neutral. But yeah, uh that's all that I want to share with you today. Uh thanks for listening. >> Yeah, please

go ahead. Um so as far as data transfer is concerned that makes complete sense um it looks really tight but what I'm wondering about is is there any point in which you do a data validation check before it goes from one party to another um as far as if that data has been compromised or you know if there's a risk involved. Is that inside your scope or

outside your scope? >> Yeah. So, um, uh, verifying the identity of the data exchange parties, that's in scope and also guaranteeing the integrity of the data exchange that's also in scope. So basically uh all the messages sent over XRO they are digitally signed, timestamped and locked. So you you can all always be sure uh that the message wasn't tampered with and uh you can authenticate the sender

>> and also if it would come from a a separate data space outside of your ecosystem as you were mentioning that's being integrated now >> same story. Well, then things get more complicated because uh yeah, like I showed in this picture, when it comes to X-RO uh those uh signing, timestamping and logging, it's in in implemented on this data plane level which is always data space specific.

So when XRO is exchanging data when you use XRO to exchange data with some other data space it really uh depends on the data plane implementation that is used. If if XRO's implementation is used then yes uh those guarantees uh they are there but then if if there is a different data plane implementation then it it might be that they they do not apply. >> Yeah. And

that's the risk of the user then essentially. >> Yeah. Okay, thank you. >> Yep. Thanks. >> Thank you.