Search

Interoperability

Interoperability is crucial for developing efficient, sustainable, and useful identity ecosystems. Specifically, interoperability is the ability of different functional units—e.g., systems, databases, devices, or applications—to communicate, execute programs, or transfer data in a manner than requires the user to have little or no knowledge of those functional units (ISO/IEC 2382).

For ID systems, this occurs at three levels (see Figure 30):

  1. Between ID subsystems (components/devices). Within the ID system itself, standards-based technical interoperability allows different components and devices to communicate with each other and work together. This includes, for example, interoperability between fingerprints captured with a scanner device and the deduplication engine, interoperability between smartcards and readers, interoperability of biometric formats captured during registration with those captured during authentication, interoperability between images captured by devices from different vendors, etc. (For more, see the Catalog on Technical Standards, or Section III. Standards).

  1. With other domestic systems. ID systems must be interoperable with other systems—such as the civil registry and service providers that are relying parties of the system—in order to exchange data or facilitate queries. Communication with other systems may be provided through various interoperability layers, web services and APIs, or direct connections. (For example, see Box 40 below on the Estonian X-road model).

  2. With ID systems in other jurisdictions. Cross-border frameworks for interoperability and mutual recognition allow credentials from one country to be accepted in other countries. This includes, for example, the acceptance of standards-compliant passports across the globe (covered by the ICAO DOC 9303 standard), as well as regional frameworks for the mutual recognition of ID credentials—e.g., the European Union’s electronic identification and trust services for electronic transactions in the internal market (eIDAS) regulations.

Figure 30. Types of interoperability in an ID system

Types of interoperability in an ID system

 

Interoperability of these three types provides multiple benefits:

  • Promoting technology and vendor neutrality: Using common standards for subsystem interoperability allows for a modular architecture and interoperability between devices, hardware, and software from different vendors. The ability to “plug-and-play” different components reduces the risk of vendor lock in and helps increase data portability across systems.

  • Improving the integrity of identity data: Interoperability with the civil register is crucial for keeping identity data up-to-date with new births and/or deaths and reducing the need for costly re-enrollment or updating exercises.

  • Creating administrative efficiencies: The ability to exchange data and make queries via domestic interoperability frameworks allows organizations to avoid duplicate data collection—e.g., to implement a “once only principle”—and inefficient, paper-based identity verification procedures. Domestic and cross-border interoperability allows applications to accept the ID provider’s credentials under a framework of mutual trust—within country or across borders—creating efficiencies in management of credentials and personal data.

  • Reducing fraud and improving targeting: For e-government, social protection, taxation, healthcare, other services, data exchange and queries facilitated by a domestic interoperability framework can help verify and rationalize beneficiary information, prevent duplicate registration, and identify previously excluded individuals.

  • Improving end-user experience: Where domestic and cross-border interoperability streamline data collection and administrative processes, it can also improve service delivery and convenience for end-users. For example, people may no longer need to repeatedly give the same information to multiple organizations or—in the case of mutual recognition—apply for multitudes of different credentials.

  • Enabling innovation and new use cases: When systems are interoperable—both in terms of subsystems and the interoperability of the ID system with other domestic or cross-border systems—this opens up the possibility of new applications and services that can be easily built on top of existing ones, which is less possible with a closed system.

Despite these benefits, the data exchange and links between systems that interoperability facilitates can create risks to privacy and data security. To mitigate these risks, some systems limit data sharing to the absolute minimum necessary or prohibit the propagation of a common unique identifier in order to reduce the ability to link information across databases. At a minimum, strong legal, regulatory, and governance structures—along with data subject consent and security and access controls to prevent data theft and regulate authorized use—must be in place to ensure that data transfers or other interoperability measures do not infringe on individual rights with regard to privacy and do not unduly put personal data at risk of theft or misuse.

The remainder of this section focuses on key issues with regard to the interoperability of the ID system with other domestic and cross-border systems, including:

  • The requirements for setting up an interoperability framework

  • Linking ID and civil registration

  • Mutual recognition of IDs across borders

  • APIs and data exchange layers (coming soon!)

For more information on subsystem interoperability, see Section III. Standards.

Box 40. Estonian X-Road Model

One pioneering example of domestic and international interoperability is Estonia’s X-Road system, which is a centrally managed, distributed data exchange layer that enables information systems to securely exchange information over the public internet. X-Road is an open-source solution that has been adopted by a number of countries and is publicly available on GitHub. In Estonia, the ability to exchange data over X-Road has allowed the government to adhere to the “only once” principle of e-government service delivery and data collection, which dictates that public sector providers should not collect data that is already available from an X-Road ecosystem member, increasing administrative efficiency and user-friendliness, and limiting the processing of personal information. Backed by a strong regulatory framework, administrative system and the technological architecture, X-Road enables secure exchange of data between systems in alignment with the privacy and data protection principles.

At the core of the X-Road architecture is the RIHA (Administration system for State Information System) information system, which serves as a catalogue for the government’s information system and provides the following:

  • The information systems and databases that make up the public X-Road ecosystem

  • Data collected and processed by these information systems

  • Services, including X-Road services, provided by these information systems and the list of users of these services

  • Responsible and authorized processors of the information systems and databases, and the contact details of people

  • Legal basis for the database operations and processing

  • The reusable components that ensure the interoperability of information systems (XML assets, classifications, dictionaries)

Box 40

 

How X-Road Data Exchange works:

  1. A user wanting to use an online service authenticates their identity via the citizen portal using their digital ID (smart card or mobile ID). A single sign on solution enables the user to request service from any department seamlessly.

  2. Using X-Road, the service obtains the data needed to process the service request from other databases.

  3. The Security Server component of the requesting system encrypts the data and sends it to the system (database) from which data are desired over internet.

  4. The Security Server at the data provider system end authenticates the requesting system and if the authorization check succeeds forwards the request to the system.

  5. The Security Server of the data provider system timestamps, digitally signs and logs the transaction and sends encrypted response, provided by the data provider system, to the security server of the requestor system.

  6. The Security Server decrypts the response and then the service processes the request based on data fetched in real time and returns the response to the user.

Source: Privacy by Design: Current Practices in Estonia, India, and Austria.