The current way of how personal data is managed is often called organization centric as organizations are managing the data and controlling how and by whom it can be used and accessed. MyData has a different approach as it aims to move towards a human centric system that allows an individual to access and control his or her personal data. Personal data is considered to be MyData if it is under the respective individual’s own control. Therefore, not all personal data is MyData, but all MyData is personal data. According to MyData principles individuals should have the right and practical means to manage their personal data, the data should be technically easy to use and accessible, and there should be a shared infrastructure in-place that enables transfer and management of the data.

Technically, the aim of MyData is not to build one centralized data storage for personal data, but rather create a distributed model where data is stored in different information systems and registers that communicate with each other through APIs (Application Programming Interfaces) using a standardized messaging model and shared, open infrastructure. The data should flow directly between a data source and a data using service. In addition, datasets should be interoperable and portable between information systems and sectors. Access to datasets should be controlled through consents by an individual.

In addition to the individual, the data subject, the model has other three key roles: MyData operator, data source and data using service. MyData operator maintains MyData accounts that store consents created by individuals. A consent gives a data using service an authorization to access an individual’s personal data provided by a data source. In other words, an individual uses the account for granting (and revoking) services access to his or her personal data. Through the account an individual should also be able to see the access logs regarding his or her personal data — which data using service has accessed what information, when. A data source is an information system that stores personal data and provides access to it through APIs. Instead, a data using service is an information system that consumes personal data provided by one or more data sources. Both data sources and data using services must implement the required MyData APIs and enable their services to be connected with MyData accounts.

In the big picture, there will be multiple MyData operators and an individual may have multiple MyData accounts. However, the aim of the MyData architecture is to make the accounts interoperable which means that individuals should be able to change their MyData operator service. Achieving interoperability requires design and standardization on e.g. data formats, trust networks and semantics. In practice, this means that MyData operator services must use the same data models and semantics, implement the same APIs etc.

X-Road Data Exchange Layer

MyData requires a secure, standardized and mature platform technology — that’s where X-Road comes into play. X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed data exchange layer between information systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

X-Road is used nationwide in the Estonian public administration and in the Suomi.fi Data Exchange Layer service. X-Road is released under the MIT licence and is available free of charge for any individual or organization. Nordic Institute for Interoperability Solutions (NIIS) is responsible for the development of the X-Road core and providing support and insights to all the interested parties.

X-Road implements a set of common features to support and facilitate data exchange. X-Road provides the following features out of the box:

address management
message routing
access rights management
organization level authentication
machine level authentication
transportation layer encryption
time-stamping
digital signature of messages
logging
error handling.

The identity of each organization and technical entry point (Security Server) is verified using certificates that are issued by a trusted Certification Authority (CA) when an organization joins an X-Road ecosystem. The identities are maintained centrally, but all the data is exchanged directly between a consumer and provider. Message routing is based on organization and service level identifiers that are mapped to physical network locations of the services by X-Road. All the evidence regarding the data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.

An X-Road ecosystem is a community of organizations using the same instance of the X-Road software for producing and consuming services. The owner of the ecosystem, the governing authority, controls who’s allowed to join the community, and the owner defines regulations and practices that the ecosystem must follow. The ecosystem may be nationwide, like in Estonia and Finland, or it may be limited to organizations matching certain criteria, e.g. clients of a commercial service provider. Technically, the X-Road software does not set any limitations to the size of the ecosystem or to the member organizations.

Two X-Road ecosystems can be joined together, federated. Federation is a one to one relationship between two ecosystems. Members of the federated ecosystems can publish and consume services with each other as if they were members of the same ecosystem. It is possible to create federation connections with multiple ecosystems, but transitive federation relationships are not supported. Ecosystem does not have a federation relationship with another ecosystem that it’s not directly federated with.

MyData via X-Road

After describing the requirements for MyData platform technology and the key features of X-Road data exchange layer solution it seems that X-Road might be a good match to the requirements. However, until now we’ve been talking about MyData and X-Road on a high level, but to be able to evaluate the match between MyData and X-Road better, we must dive into the details.

X-Road can be used as a data exchange layer between data providing services, data using services and MyData operator — for transferring both consents and data. In addition, access logs created by X-Road are transferred from X-Road Security Servers to MyData operator via X-Road too. In fact, all data exchange between different data exchange parties is implemented using X-Road’s standard message exchange protocol. In this way, X-Road takes automatically care of several security controls that otherwise must be implemented separately for every new connection between data source and data using service, data source and MyData operator, and data using service and MyData operator.

The use of X-Road requires that all the message exchange parties are members of an X-Road ecosystem and they have access to an X-Road entry point, Security Server, which is required for both producing and consuming services. The Security Server mediates service calls and service responses between information systems, and it encapsulates the security aspects of the X-Road infrastructure: managing keys for signing and authentication, sending messages over secure channel, creating the proof value for messages with digital signatures, time-stamping and logging.

X-Road logs contain all the messages processed by the Security Server. Each message is time-stamped and signed which makes it possible to verify the message content afterwards. By default, the logs are stored locally by the Security Server — external parties do not have access to them.

Both data using services and data sources are identified using X-Road’s globally unique identifiers. The identifiers contain information about the X-Road ecosystem, member organization and information system that is consuming or producing data via X-Road. The identifiers of data using services consist of 4 parts (1–4) and the identifiers of data sources consist of 6 parts (1–6):

X-Road instance identifier — identifier of an X-Road ecosystem.
Member class — type of member organization, e.g. governmental (GOV), commercial (COM).
Member code — business ID of a member organization.
Subsystem code — identifier of an information system connected to X-Road.
Service code — service code of a service that can be consumed via X-Road.
Service version — version number of the service.

The identifiers are used internally by X-Road for routing messages between data using services and data sources. A data using service does not need to know the network address of a data source — X-Road automatically maps the service identifier to the correct network address.

Built-in features provided by X-Road can also be used for managing access rights to data sources. Access rights management is based on the X-Road service identifiers. The key idea of X-Road is that each service provider owns its data and is responsible for managing access rights of its services. In other words, publishing a service to X-Road does not mean that the service is automatically accessible to all X-Road member organizations. Usually, access rights are granted on information system level — a service provider grants a specific information system access to a service. This approach provides a tight control, but it may also generate lot of administrative work if the number of service consumers is changing frequently.

Image 5. MyData access rights management based on X-Road service identifiers and global groups.

X-Road provides a feature called global groups that allows a service provider to grant a specific group of information systems access to a service. All the information systems that are members of a global group will then have access to the service. The members of the group are centrally managed by the X-Road governing authority so it’s possible to limit the membership of a group to organizations meeting certain criteria. This allows creating a global group for MyData data using services that contains only information systems that are registered as a data using service by a MyData operator. MyData data sources can then grant the global group access to their MyData services. In this way, all MyData data using services have access to all the MyData data sources through a single group membership. To make this work in practice, a process for synchronizing MyData data using services between the MyData operator and the X-Road governing authority is required. Technically, global groups are maintained on the Central Server operated by the governing authority and automatically distributed to all the Security Servers.

Image 6. MyData request flow via X-Road.

Using global groups data using services can be granted access to all MyData data sources. However, data using services are not allowed to fetch just any individual’s data — they need to be authorized by the individual to do so. Before requesting an individual’s data from a data source, a data using service must check that a consent created by the individual exists in MyData operator’s database. Without the consent a data using service has no authorization to request an individual’s data from a data source. The consent may be checked by a data using service only, or by both a data using service and a data source. If the consent is checked by a data using service only, a data source trusts that the data using service is authorized to access the individual’s data. From X-Road’s point of view both approaches are supported, and they can even co-exist within the same X-Road ecosystem. Either way, unauthorized use of an individual’s data can be automatically detected by analyzing the logs that are collected by the MyData operator and comparing them to existing consents. Unauthorized use of data may be subject to penalties, e.g. exclusion from the service etc.

The Perfect Match?

MyData requires a secure, standardized and mature platform technology — and X-Road meets the requirements. X-Road creates a trust network where the identity of each organization and access point is known and can be verified. In addition, X-Road provides several built-in security features that make data exchange secure and traceable and guarantee non-repudiation of the data sent via X-Road. Access rights management between data using services and data sources can also be implemented using an X-Road provided feature, global groups. In addition, X-Road supports the model of multiple MyData operators and MyData accounts.

X-Road is based on distributed model which makes it resilient against cyberattacks and service interruptions. The first version of X-Road was released in Estonia in 2001 and the concept has proven to be successful even if the implementation technologies and software versions have changed over the years. In addition to Estonia, X-Road has been implemented in Finland and many other countries all over the world. Different X-Road ecosystems can be joined together, federated, which makes it possible to consume and provide services between ecosystems. This feature can be used to exchange MyData between X-Road ecosystems too, e.g. cross-border MyData exchange between Estonia and Finland.

X-Road is an open source technology, and anyone has access to it for free of charge. An X-Road ecosystem is managed by a governing authority that controls who are allowed to join the ecosystem. In Estonia and Finland the ecosystems are open for all kind of organizations (public, private, non-profit etc.) and joining them is free. Joining an X-Road ecosystem does not require an organization specific Security Server as a Security Server can be shared between multiple organizations or provided as a service by a third party, e.g. a commercial service provider. The process that is required to join an ecosystem is more time consuming compared to implementing a direct point-to-point integration, but it is necessary for creating trust between the members of the ecosystem. In addition, the process is required only when a new organization joins the ecosystem or a new Security Server is registered.

Despite everything X-Road can offer, it alone is not enough to answer all the open questions regarding MyData platform technology and interoperability. X-Road provides a secure and standardized way to exchange MyData, but it does not enforce semantic interoperability, common business data models and standard business APIs. X-Road provides a framework for data exchange, but it does not process or transform the business data that is transferred — that is out of its scope. In addition, X-Road provides a technical framework for service level access rights managements, but to make the model work in practice, a legal framework for service agreements between data sources and data using services is required too. Besides that, X-Road does not provide implementation of MyData operator and consent verification either, so they must be implemented separately. X-Road also sets some requirements to their implementation as the service identifiers used by X-Road must be included in the MyData operator’s data model and consents. In addition, also X-Road requires some further development to make implementing all the presented features possible. For example, X-Road does not currently provide a mechanism for sharing log entries in a way that enables accessing them from an external system and providing a centralized view to access logs.

All in all, X-Road provides many features that are required from MyData platform technology. Instead of developing everything from scratch, X-Road provides an alternative with a solid starting point that enables targeting resources to missing components and open questions. X-Road is an existing and operational system which allows testing new ideas and approaches from day one instead of waiting for weeks or months.

NIIS is responsible for developing X-Road core technology, and welcomes everyone to submit new ideas and enhancement requests regarding X-Road and MyData. X-Road’s backlog is public — anyone can access it, leave comments and submit enhancement requests through the X-Road Service Desk portal. Accessing the backlog and service desk requires creating an account which can be done in few seconds using the signup form.

This article was originally published in the MyData Journal on the 31st August 2018.