Introduction of X-tee
This documents aims to explain the essential nature of the X-tee using easy to understand language.
It is a guide intended for those who want to acquaint themselves more thoroughly with the X-tee (e.g. those who are working for an organisation which will soon join the X-tee). It introduces the X-tee’s complex terminological system slowly and in a comprehensible way, so that the reader can painlessly achieve the preliminary familiarity with the X-tee necessary to engage with more explicitly technical and complex manuals.
Author: Anto Veldre, Analyst
Written in February 2016.
Topics to be covered
- Modern governance – why do we need IT to govern a State?
- What are the necessary considerations in keeping databases secure?
- Why was X-tee created?
- Numbering people as a foundational principle of the modern e-State.
- What is a “security server” and what is its purpose?
- X-tee participants and their roles: Who does what and how is the bottom line determined?
- Explaining complex terminology and the final quiz.
Before we begin...
It is important to keep in mind that because all software is created to solve some particular problem or complete some specific task, every piece of software has a purpose. When discussing a particular piece of software one cannot forget about its context and the initial task that particular software was developed to solve.
Take the example of text editors—text editors clearly assume some level of literacy from their users. Further, to use a text editor to prepare a cover letter for a job application, one must be familiar with certain writing conventions: what to put in the heading, what to write in the subject line, etc.
Another example: even if the average person was given access to working AutoCAD software, there is a high probability they would not be able to design a house with it because they do not understand how to take advantage of the tools available via AutoCAD. A final example is the grandmother who cannot play her grandchildrens’ computer game because she lacks critical knowledge about whom to hit and which key to use to “fire!”.
So too, could the essence of the X-tee and the rationale behind such a complex system remain incomprehensible to users who lack extra background information.
Below we will give the reader the essential knowledge necessary to make sense of the X-tee.
The State and Governance
A frequent confusion about the purpose of X-tee stems from the fact that this software is designed for State institutions and organisations to use in the course of exercising their duties, not for individuals’ home use.
For a State to function, several conditions must be met:
- Persons have to be identified (so that d'Artagnan cannot present himself as Swedish King). Each person should have a unique numeric identity.
- A numeric identity must be assigned to land properties, vehicles, businesses and addresses.
- Since persons, addresses, land properties are in constantly changing relationships with one another a lot of data has to be gathered on relationships, deals and procedural interactions (e.g.: who marries whom; whether rents and duties were paid, whether sales permit was issued or military conscription served).
This sort of data is highly complex; a variety of variables must be recorded, for example persons' names and personal data, family data, addresses, business relationships, titles, property maps etc.
Without systemised data of this kind we will not have a State but a pack of hunters-gatherers or an unorganised group of countrymen.
States have historically used clay tablets, parchment, and paper in governance. The modern State is maintained via computers and databases because these technologies allow for greater speed and complexity. We are able to form ever more complex associations and paper forms are constantly being replaced by databases and web forms. Just 30 years ago, obtaining certificates and attestation papers was a time-consuming task. Today, we print filled forms out straight from the Web. It seems a little unbelievable, but in Estonia one can leave his or her drivers' license at home—identities and driving privileges are checked electronically. Today, physical cards for social security are a thing of the past.
To attest somebody’s last will could take years of archival research in medieval times, but today, assuming the law contains no logical doublespeak and the genealogical relationships are properly recorded in a database, a similar request can be executed within seconds.
In summary, a state without data on its citizens is impossible in principle and today the quality of both governance and life quality are predetermined by the speed of services.
When speaking about security, we must first turn to the issue of confidentiality, i.e. who can access the information and on what conditions. To a certain extent, data integrity threats will also be considered - i.e. can some actor change the information without leaving a trail and can the data be protected and retained intact (only 11 gnawed pages have been survived the oldest printed Estonian text – Wanradt-Koell Chatechism, 1535).
One of the biggest threats to the State is an uncontrolled centralisation of data into a single database. Historians remember the Great library of Alexandria burned down. The risks inherent in this approach are clearly illustrated by the use of imported punch card sorters to select and target certain social groups in 1930s Germany [IBM and Holocaust, Edwin Black »].
Another example of the threat posed by centralised databases manifested itself on September 26, 1996 when Estonian national television reported on the usage of an illegal superdatabase created by hacker Imre Perli. We were shown the search of home address by the owner's name, the financial obligations of the Prime Minister and other private data. Three months worth of call records metadata from the largest mobile provider were also compromised in the hack, but they were excluded from the broadcast. [See seaduslik ebaseaduslik info…, Armin Berlin, Luup (1998) nr. 21, lk. 44–47].
Why is such kind of a super database dangerous? In theory, the State should possess a monopoly on its citizens' data. The existence of centralised databases makes interference with this monopoly more likely. I recall driving around in Tallinn in 1996: when somebody broke the traffic rules or misparked, it was possible to look up his mobile number and call him right then – certainly a very frightening possibility. The State has reserved to itself certain rights, fellow citizens must not engage in intelligence activities.
Estonia has never officially recognised 1996’s huge data leak and the leak’s perpetrators have never been sued. Despite this, the hack was a learning experience and ever since Estonia has tried to avoid centralised databases. The risk of centralised databased has long been discussed in other countries. Cambridge information security professor Ross John Anderson even derived “Anderson’s Rule”: if a large system is designed for ease of access it becomes insecure; if made watertight it becomes impossible to use ».
Another potential trap in database systems design is related to data integrity. Any government that attempts to record ALL of its citzens personal data will make some “mismatches” where personal data is updated in one database but not another. As a result, duplicate records about a person will appear with different data and it will not be possible to say which of those are accurate and which are not. Some states have been tried to avoid the issue by synchronising multiple databases, but these efforts have been frustrated by time constraints – it is not so easy to transport Gigabytes across large distances. Imagine learning that your yearly credit limit is exceeded in one region but not in another, can you spot the problem with the approach that would let this happen?
Vice versa, after raising the requirement that some particular data must only reside in one certain database (lets call it “the original”), the data quality issues here evaporate.
An idealistic design
We probably should start stating that knowledge is power. The more data, the bigger power. The main task of a democracy, however, is to distribute power. That leads us to the logical notion that in a democratic society, the databases probably shouldn't grow too large. Each office should have its own database but, leaving entirely aside the issue of pirated copies of illegally collected data, they should not have the copies of the states’ remaining databases.
That notion leads us to the next issue: how to execute complex database inqueries? E.g. a homeless pet with microchip implant was found on the street, how do we determine its owner? To do this, we would need to send two requests: the first to the Pet Database and the second to the Population Register. This does not necessarily mean, however, that we need a trusted database specialist who has right to enter both government databases. Having such a specialist raises the same issues as the Super Database described above. Other problems with this approach include the need for several sequential requests (slow!) and the use of the public Internet (dangerous!).
The technology that we today call the X-tee grew out of Estonia’s efforts to solve these thorny issues and deal with these trade-offs in the late 1990s and early 2000s. So far, there haven't been any events that have severely hindered the X-tee. This resiliency suggests that the distributed architecture works remarkably well even in critical situations (like cyberwar).
Uuno Vallner » recalls that the State Information Systems Department » (at the Ministery of Economy and Communications) initiated the X-tee project around 1998. The pilot was ready in 2000 and was shown at a public conference. Three databases were interconnected and their data was exchanged according to the XML-RPC » standard. The main development was done by Tanel Tammet, Hanno Krosing and Vello Kadarpik, all of whom are famous in Estonian IT. One of the biggest challenges facing these developers was whether to use the proprietary technology of a corporation or try to manage using the free software.
In those years, Uuno's main interest was the creation and deployment of SGML/XML » based applications. Vello had used XML services while working in finance and those experiences led him to the idea of incorporating XML RPC applications into the public sector. In 2000, the State Information Systems Department ordered a thorough concept analysis from Professor Tammet (XML applications and XML-RPC based prototype). Later, a tender document had SOAP » preference but the winner – Assert (Currently Fujitsu & Actors) gave preference to RPC – for the simple reason that SOAP technology hadn't yet reached maturity.
The project was managed by Niilo Saard and Aleksander Reitsakas. One of the subcontractors for Assert was AS Cybernetica. They had a huge influence on the X-tee via their programming of the logs chaining module. Today Cybernetica has taken the lead role in the development of the X-tee. As an aside, the initial name of this technology wasn't "X-tee" but "Crossroad(s)" (Ristmik).
The X-tee was initially launched in 2000 in the cellar of the then existing Informatics Foundation, on Toompea Hill. Early X-tee personnel include: Ahto Kalja, Riho Oks, Juhan Vene, Martin Undusk, Andres Kollist, Uuno Vallner, Katrin, Peeter. Most of these individuals were employed by the State Information Systems Department but some were on the payroll of the Informatics Foundation (Imre).
One thing that is important to understand about the X-tee is that it is not a fundamentally new invention. Estonia simply harnessed then existing technologies and applied them in a novel way in the state governance context. The outcome of this novel application of existing technologies was named the X-tee.
Deeper scientific research on the e-State was proposed by Arne Ansper (currently CEO of AS Cybernetica) in 2001. Excerpted below is a two paragraph long quote from the research abstract:
"This far, the Estonian public administration databases have been kept isolated from each other. The data exchange between them has been slow and inefficient. Fast and reliable data communication networks between state agencies removed the major obstacle on the way of tighter integration of public administration information systems. They have created a possibility to make communication between state agencies faster, safer, and more efficient. To exploit the advantages of new technology, public administration databases should be made accessible not only to one single agency, but rather, to all authorised persons who need that information for doing their jobs more efficiently (and thereby, for improving public services in general). Such a renewed Internet-based public administration is called e-State.
In this work, we analyse the security problems that arise when the public administration databases are opened for a widespread electronic access. The analysis is grounded on the current legal situation as defined by Estonian laws. We present separate analysis for agency-to-agency and for citizen-to-public-administration data exchanges. During the analysis we draw an important conclusion that, due to substantially different scopes of risks and the countermeasures available, security solutions developed for business organisations cannot be directly adopted for using them in public administration environment. As a result of the analysis, a model for the e-State architecture is presented that, together with appropriate legal framework, allows us to achieve the main security objectives."
The main postulates of X-tee
- The solution shall work over the generic commodity Internet (it was cheaper than direct lines and Estonia was more cost-sensitive at the time of the X-tee’s founding).
- Each connected institution shall be strongly identifiable via a cryptographic certificate. This requirement helps prevent against the possibility that someone could enter (and then purge) the database via some airport WiFi.
- Cheap does not mean insecure – all the X-tee communications are encrypted. In contrast to a commodity VPN, which is constantly online, the X-tee puts up TLS/SSL tunnels only when data is actually being exchanged.
- Each data owner can enforce its own additional conditions. For example, one data owner might require that every person making a request on behalf of an Institution Certificate, must be 100% identified. This requirement would be easy to fulfill in Estonia because of personal numbers and Estonian eID cards.
- Actions are constantly logged, and logs are chained and have non-repudiation value. Requests are counted by persons that initiated those as well as by institutions. This counting helps to predict productivity bottlenecks as well as to monitor the security situation.
- There are no free-form requests like “find all black cats on the White Street” allowed. All request templates are pre-fabricated. This structure makes it much easier to log requests. A logged request might look like this: On the 15-th Day of September Anno Domini 2015, precisely at 13:47:12 and 85 micoseconds, the Person numbered as 37412029381 on behalf of the Business Register Entity no. 12345678 made a “Find-The-Owner-Of-The_pet.wsdl” (WSDL) request against the “Pet Register”.
Mutually complementing views?
Official manuals describe the workings of the X-tee in great detail. In this document, we will provide simplified description of the X-tee aimed at facilitating simple engagement with the X-tee technology.
One issue with understanding complex objects is that your perspective depends on your location with respect to the object. If you approach from a different angle, it could look completely different.
The essence of the X-tee is a pipe transport system, or, if you prefer a stellar stargate system, to ensure connectivity among participants. Thus, the first step to engaging with the X-tee is to hook into the pipe system, i.e. get membership of the X-tee Club. After your building has been outfitted with piping, you can make requests of the pipe system’s other constituent members. Still there is a limitation: you only can request data from those with whom you have a usage agreement.
In other words, your organisation’s membership in the X-tee will give you access to the pipeline transmission system. But only via agreements with each particular data provider will your organisation be able to access other members’ data. Further, and more importantly, you will be able to access the data of another X-tee member only in accordance with the terms of your agreement with them. Here are several examples of the types of extra terms data providers might impose on those seeking access to their database: 1) each request must be submitted with the personal number (isikukood) of the person initiating it; 2) before even letting a person make requests on behalf of an organisation, his/her identity must be 100% proven. This condition is easy to meet in Estonia because of the authenticated identities provided by Government accepted certificates.
We will now examine X-tee usage scenarios, various participants’ roles, and the legislatice and technological aspects of the X-tee and its use.
The absolute majority of X-tee users are passive users. Occasionally they make requests against databases and registers but they do not possess their own databases. Or if they do, then it is a local database which is not be shared with other X-tee members.
The most important X-tee users are data service providers. They make their data accessible for other members or, alternatively, collect new data from others. All state registers are data service providers. “Providing data” has two sides: a technical one and a legal one. To keep an official database, even if one does not share its data, an organisation must register the database with RIHA. RIHA is a local abbreviation for the State Information System’s administration system.
It is possible to simultaneously share and request data from others via the X-tee. For example, an organisation might be requesting data from databases A and B, while at the same time collecting data from a citizen and recording it in its own database, C. Once recorded, that information in Database C can be shared with other X-tee members, including the institutions responsible for databases A and B. Last but not least, it becomes possible, based on the personal code of that citizen, to make a complex simultaneous request against databases A, B, and C and to get a joint answer containing data from all three.
It is possible for users to simultaneously read and update X-tee data. The X-tee can also support complex queries that involve querying e.g. 37 related databases. The request a policeman makes while issuing a speeding ticket, for example, is among these. By the way, we call a finished question-answer cycle an interaction.
Identificators have a special role keeping an e-State up and running. Citizens and residents are each assigned a unique personal number (isikukood). Dogs and cats, important objects like real estate, agreements, outgoing mails, are also all assigned unique numbers.
Personal numbers are the most important identifiers in an e-State; these IDs are the only correct way to distinguish numerous Mr Smiths from one another. People identify each other using facial and voice recognition but robots and computers cannot do so; for them, a numeric identificator is a must.
- The Estonian X-tee has a Centre. Today, this centre is maintained by the State Information System Authority, the successor of the Estonian Informatics foundation. The centre accepts new members, issues the access credentials (certificates) that are needed to access the X-tee services, defines the X-tee Code of Conduct, and monitors the actual usage patterns using a special software. The Centre has assigned people and pre-defined procedures for managing the X-tee’s structure.
- Members / participants – any legal entity (even private entrepeneurs) whose membership application has been approved may use the X-tee. A member's computer can only access the X-tee resources in accordance with its legal agreements with other members’. This feature is very similar to the serial number check used to limit accsss to some popular software programs.
- A completely new class of Actors is Trust Service Providers (i.e. those who provide services like timestamping, certification etc). Trust Service Providers do not provide data via the X-tee. Instead, they offer some standard cryptographic service that raises the trustworthiness of the data provided by someone else.
As a result of the X-tee’s distributed architecture, the Centre’s involvement is not necessary for proxying or answering data requests. The role of the Centre is to distribute the list of X-tee data service providers. Provided an institution is not being advertised in this X-tee “phonebook” it remains invisible to other X-tee members.
The X-tee legal framework has two levels. After obtaining membership in the X-tee, an institution or company is assigned codes, numbers and certificates for identification and authentification. It then becomes sighted: it is able to “see” the interface servers and request the interface templates of other participants. However this visibility is very limited; X-tee members can only see a very generic overview of other X-tee users’ interface templates.
With the exception of some sample-databases made available for testing purposes, actually using a database (a Register) requires making a detailed agreement with the database’s owners. Let's summarise the legal procedures an organisation must go through to use another organisation’s data via the X-tee. Imagine a municipality wants to process captured cats and reunite them with their owners.
The municipality must:
- Become a member of the X-tee by entering into a contract with RIA, Estonia’s Information Authority.
- Make an agreement with the Pet Register. In order to make this agreement the organisation will have to provide an estimate of the number of requests per day.
- Make an agreement with the Population Register. Making this agreement will require proving that the organisation’s access to the personally identifiable information contained in the Population Register is necessary for completing a public task. For capacity planning purposes, estimates of the number of anticipated requests must also be provided to the Population Register.
- Secure the technological and operational ability to interact via the X-tee. This means obtaining servers, installing the X-tee software, and maintaining the system. In some cases it is possible to outsource this technical work to someone more capable outside the organisation.
Techno, Techno, Techno... Tehnological Aspects of X-tee Participation
After the legal requirements of interacting with the X-tee have been met, one must tackle the technical aspects of communicating via the X-tee.
That Magical Security Server
Regardless of your X-tee membership type, you cannot avoid interacting with a security server.
The name “security server” is probably a too generic and thus not very helpful for understanding how the device actually works. A security server is actually a OSI Level 7 Application Gateway » that reworks and redirects “requests”. “Requests” are those requests for data asked in the X-tee dialect by the information system of a X-tee member. It is the security server that enumerates possible target databases, translates register names into IP addresses, encrypts the traffic, and produces the request statistics etc. Interestingly enough, the software behind the security servers is free and anyone can download and install it.
Even with a security server, one cannot access the X-tee without the codes and certificates issued by the centre. From the user's perspective, the security server is a necessary, but not sufficient, component for X-tee access. In order to access the X-tee, the security server must be properly configured.
The Security Server packages data requests in a cryptographically sound way so that the request is only accessible by the intended recipient. The security server also protects requests sent over the X-tee from eavesdropping, unauthorised change, loss and duplication.
An interesting fact: a single institution or organisation could have multiple security servers. An organisation with a high volume of requests might do this to distribute its request load and ease the burden on a single server. Alternatively, an organisation might want to rent security server space to smaller institutions.
Making use of X-tee
I'm only asking
A consumer (or client) user of the X-tee is limited to making requests via the X-tee. Generally requests will not be initiated manually. Instead, a relevant request-making functionality is programmed into the IS of particular institution/company. The request must adhere to X-tee Messaging Protocol (there are several versions available) and will then be pushed into the security server on the initiator side. After being encrypted and formatted, the message moves on through the magical X-tee pipeline until it lands in the target institution's security server.
The cryptic name "OSI Level 7 Application Gateway »" obscures the complexity of the X-tee’s pipelines. The IS of the requesting user will send a POST request against his own Connectivity Server, e.g. myconnectivityserver/CatsData.Estonian-Xtee/FindTheCatOwnerByCatsMicroChipNumber?123456. Once the POST request has been sent and answered, the answer to the user’s request appears, as if magically. In the case of the organisation seeking to process stray cats, for example, the “request” initiated when the cat’s chip is queried is responded to with the personally identifying information of the pet owner. Accomplishing the same task without the X-tee would require a bunch of usernames and passwords, the relevant servers' IP addresses, and knowledge about how to effectively use SQL (Structured Query Language). As a result of the X-tee, users can initiate requests without needing to know how to reach the registers, or even how to produce valid SQL sentences.
Both the initiator and the target of the request have their own numeric identity. This numeric identity could, in the simplest instances, just be their identity in the Business Register. It is relatively easy to save both parties’ numbers in a request log. This logging makes it possible to prove at a later date who has made what requests of which databases. When operating databases that require high security, data providers can impose extra requirements for access. For example, they can require the personal ID number of the person behind the request, or require eID to finalise a request.
Even if your organisation is technologically compatible with the X-tee, if it does not have an agreement with the data owner from whose database you are requesting data, your request’s outcome is very simple: your request will not be honored because you do not have sufficient access rights.
Providing answers to consumers
In contrast to consumers, who make requests via the X-tee, data providers use the X-tee to answer requests and share data. Data providers must meet two extra requirements to use the X-tee.
- First, data providers must have a Register (database) to grant the access to. This Register must have been registered with RIA. Through the registration process it is possible to limit who has access to the database.
- Second, data providers must have an Adapter Server, commonly known as “integration components.”
Adapter servers are not standardised. Each set of integration components will solve a given task a little bit differently. The important functions of the adapter server are: parsing the requests that arrive via the X-tee, translating these into a language understood by the local database - the X-tee does not circumscribe organisation’s ability to use whatever database platform they please - and directing answers back to X-tee pipeline. Data providers can procure these adapter servers from whatever software company they prefer.
Adapter servers also check arriving requests against the requested WSDLfile, so continuing with our stray cats example, the adapter server may check the request against the “FindTheOwnerByChipNumber.wdsl” file. The adapter server will only forward the request to the database if the request is grammatically correct and if the originator the request is on the access control list. Adapter servers also forward the answers back across the X-tee to the request initiators.
A data provider’s adapter server must be registered with the X-tee centre and with RIHA. If the adapter server is not registered then the X-tee centre cannot advertise its services back to potential consumers. RIHA registration also facilitates convenience since it allows all WDSL files to be centrally published, and by extension, public, described and understood.
A short note to hackers: you cannot use an adapter server to access the X-tee from your home because you have neither data to share nor clients.
Another feature of the X-tee is MISP (mini-information-service-portal), a standard web portal to enable trivial requests that conform to prescribed parameters. The MISP makes it possible for users to access the X-tee via a normal internet browser. It does this by translating WDSL files directly into webpages.
MISP is intended for small and low budgeted institutions that are legally required to publish data of some kind. MISP makes X-tee participation more convenient for these organisations, which might otherwise be thwarted by the complexity of X-tee participation.
Even organisations using MISP must have a security server. Several private companies provide joint MISP + Security Server solutions to smaller municipalities. A tiny municipality will save a lot of money by not building its own server room.
MISP is only accessible to those who have logged in using two-factor eID. Further, for security reasons, MISP cannot be used to execute complex requests or access especially confidential information.
Ancillary Information about the X-tee
It is impossible to counterfeit requests and data on the X-tee
As noted above, every interaction that occurs via the X-tee is logged. Requests are always logged. This constant logging facilitates one of the X-tee’s most important design goals: data integrity. Only authorised persons should be able to access, modify and erase data via the X-tee.
All of this sounds good in theory, but how are these security requirements ensured in real life? First, the X-tee Centre collects statistics about X-tee usage from the security servers. This enables it to know what requests were made of data service providers. Sometimes a single request will be flagged as anomalous and the Centre can then ask the initiator to clarify its grounds for making the request.
Additionally, each security server has a security log reflecting every request it has ever made.
There are several options to ensure the continued integrity of the logs. One of these is chaining, which means making latter logs cryptographically dependent on those that precede them. Chaining makes it impossible to fabricate events.
It is also possible to digitally sign and timestamp requests made in a given time period (day, month, year). This makes it possible to later determine with a high level of certainty whether a request was ever made or not. In other words, requests are non-repudiable. This means, no one can deny they occurred or change the details recorded about them. For these reasons, starting with X-tee version 6, Secure Signature-Creation Devices (SSCD's) are used by all X-tee participants. These devices enable fast and secure digital timestamping.
One of the main principles of the e-State is that no one should be able to forge records. Security logs are central to ensuring this data goal. Regulations and procedures that make the professional and legal costs of attempting to forge records very high are another important tool for protecting data integrity.
About Duplicates: the dog named "Cat"
When the X-tee was born, it existed in only one place (the RIA-controlled X-tee Centre). In other words, it was impossible to differentiate between the abstract idea of "X-tee technology" and the applied "X-tee System": these seemed to be one and the same. But then, private companies and neighbouring states took notice of this very useful technology and wanted to install X-tee technology for their own internal use.
This replication of the X-tee technology caused a problem. When two X-tee communicate with each other, things can get messy. Imagine that you have two dogs in your house, both of whom are named “Cat.” In this case, when you holler for "Cat", it is not clear which of the dogs are you calling. To solve this problem, the "instance name" attribute was added to the X-tee technology.
In the future, when the X-tees in Estonia and Finland wish to communicate with one another, they could have the instance names "XTEE.EE" and "PALVELUVÄYLÄ.FI" respectively. Similarly, the X-tee of private companies could theoretically communicate with one another via instances’ names like XTEE.SIEMENS or XTEE.PHILIPS.
A superstructure joining several X-tees is called a federation. A federation enables data exchange between the clients of different governments. A multi-instance federation has not yet been launched, so we don't know who would govern it or how it would be managed. Perhaps Estonia’s RIA, or alternatively, the EU might take key roles.
About Data Exchange
And now, some light-hearted commentary about the terminology surrounding the X-tee.
The official X-tee documentation often mentions "Data Exchange". This phrase has a specialised meaning within the context of the X-tee.
When a policeman stops a car and makes an inquiry about it and its driver via the computer in his patrol vehicle, that request is transmitted via the X-tee.
Specifically, the policeman produced a request which was transmitted as bits of data via the X-tee and a little bit later the answer arrives back to his patrol car computer, also via the X-tee. This set of interactions is a "data exchange".
In the context of the X-tee the phrase "data exchange" should be interpreted narrowly. Registers do not "swap" data with one another; the data itself is not updated or modified. The word "exchange" here simply denotes that data is transmitted in both directions - the request data is sent from the initiator to the data provider and the response is sent back.
On the directionality of the data service
The directionality of data service is important. There are usage scenarios in which a customer simply asks for some pre-existing data. However, there are other usage scenarios in which the customer seeks to update data.
For example, when a person is born, a whole new record is created. Similarly, when someone moves, the address field associated with them is updated etc.
Below are a few short quizzes to help you test your knowledge about the technical aspects of the X-tee.
The following advertising slogan is displayed on the website of AS Cybernetica to promote the X-tee:
- In what ways is the X-tee the backbone of Estonian State?
- What are the X-tee’s information security features?
- What does it mean that the X-tee is “distributed”? What was the role of the late Imre Perli in highlighting why the X-tee should be distributed?
- Please explain your understanding of a “service bus” mentioned on the screenshot. What is transported by the service bus?
- What organisations and individuals exchange data via the X-tee? Please give at least one practical example.
- Why has such a complex system been created to exchange data? Why can’t data be “exchanged” itself without the involvement of specialised technologies?
- The X-tee is the backbone of the Estonian State because the absolute majority of registers and databases kept by the Estonian State, are made available via X-tee. Without X-tee, if the State wanted to store and exchange its data it would have to build a Central SuperDatabase or establish a horse sleigh company to move data storage devices between municipalities and agencies across Estonia.
- There are three core tenants of the information security: data availability, integrity and confidentiality. Provided the X-tee is functioning properly data availability is taken care of. The X-tee’s security features exist to promote data integrity—via the frequent creation of non-reputable log records—and data confidentiality—by limiting data access to those authorised people working within organisations authorised to access that particular set of data.
- The X-tee’s distributed architecture was designed: 1) to avoid the risks inherent in a central superdatabase; and 2) to avoid the seemingly unbearable price of central IT solutions of 90-s. Imre Perli was a hacker whose data theft highlighted the risks inherent in having centralised databases.
- This is data that moves back and forth via the data exchange bus.
- Data Exchange is a crucial term. When customer makes a request and gets an answer, then bits move around the data bus in both directions – an interaction has been made. The data involve may or may not be modified in the exchange.
- Data availability, integrity and confidentiality is s only possible when protocols and rules are strictly defined and followed.
Read the following sentence (from a manual)
"The data exchange layer for Estonian state information systems, X-tee, is a technological and organisational environment enabling a secure Internet-based data exchange between X-tee members",
and try to answer these questions:
- What does “State Information System” mean?
- What does the phrase “Data Exchange Layer for the State” refer to?
- What does the phrase “Technological environment [of X-tee]” mean?
- What does the phrase “Organisational environment [of X-tee]” mean?
- What type of data do state databases exchange with one another?
- Who are X-tee members and how does one become an X-tee member?
- The state information system includes: databases, client programs that officials use to access data, e-mail programs, network connections and web servers.
- When the X-tee began it was only accessible by public sector entities. However, it soon became clear that including private companies in the X-tee would yield great efficiency and convenience.
- The X-tee’s technological environment includes servers, computer programs, internet connectivity etc. Pure IT, nothing more!
- The X-tee’s organisational environment includes rules and procedures, for example those governing how the X-tee is managed and who is responsible for what aspects of its maintenance.
- During an interaction, a human and a database exchange bits of information. A “Data Exchange” is everything that happens during this interaction cycle.
- Basically anyone can become an X-tee member (even a private enterpreneur) provided the membership application was approved by RIA (Estonia’s State Information System Authority). However, entities get X-tee membership not for fun, but because they have an institutional need exchange data faster, more conveniently, and with lower overhead.