Citizens will not be able to use the digital services offered by public administrations unless the data related to their applications are transmitted securely and reliably to the competent authority. There are still a number of pitfalls in the interaction between OZG portals, data centers, municipal authorities, and their specialized procedures that must be avoided, however, when realizing the transfer of these enormous quantities of data during the implementation of the OZG
The objective of the Online Access Act [Onlinezugangsgesetz; OZG] is the creation of a digital interface between public administration and German citizens. The aim is to have topic portals and digital applications on the web that can be used in combination with digital identities in service accounts to request performance of administrative services. But how do the data relating to the citizens’ applications ultimately reach the government authorities?
The response to this question was the development and introduction of the so-called 4-corner model as the standard for the OZG. The model is supposed to provide at an abstract level a simple means of transferring the data from the online services (the digital application paths) to the specialized procedures of the authorities.
In practice, however, it becomes apparent that this model often falls short of requirements and that operational circumstances in the data centers or political and legal constraints make a straightforward implementation of the 4-corner model impossible. Some of these challenges and possible approaches to solutions from actual practice will be presented below.
The 4-Corner Model
Transmission standards such as XTA2 and OSCI have been established in public administration for the transmission of application data. They serve as the fundamental form for message transfer in the so-called 4-corner model and consequently in OZG as a subarea of e-government. The standards and the challenges presented here are also relevant as a technology for other subjects such as register modernization, EFA implementation, and the realization of single digital gateway (SDG) or the once-only principle.
The first corner of the 4-corner model (see Figure 1) is the application portal (Corner 1, “Online Service”), which acts as the author of the message being transmitted. The content-related message is traditionally created using an XÖV format. The online service itself or the management portal then traditionally transfers the message to the sender (Corner 2) as an XTA2 message. The function of the sender is performed by an XTA server that has access to the German Administration Services Directory (DVDV). The public keys of the recipients stored in the directory are used to encrypt the XTA messages before they are packaged as OSCI messages in accordance with the “double envelope” principle and sent via the OSCI intermediary.
Even though the OSCI intermediary only processes the received message, it is categorized in the role of the recipient in the 4-corner model (Corner 3). The recipient decrypts the OSCI message and finally retransmits it in XTA format to the reader for whom its contents are intended. The role of the reader, the fourth corner, is represented in the model by the specialized procedures of the administration authorities.
Viewed from the perspective of the integration of specialized procedures, the OSCI intermediary interface represents the access point to the various specialized procedures and employs the double envelope procedure to ensure the confidentiality of the message data. Thanks to the use of the XTA standard at the beginning and end of the data transmission paths, the sender can connect to a multitude of online services and the connection of recipients to several specialized procedures is also facilitated.
Use in practice
As is a common feature of abstract models, the 4-corner model sometimes generalizes broadly, overlooking local conditions that stand in the way of a simple implementation of the model.
Initial consideration of the 4-corner model can lead to the assumption that the OSCI intermediary as recipient is always operated at the receiving authority as well. This is essentially possible, but actual realization in practice often takes a different route. Since the setup and operation of an OSCI intermediary is complex and requires specialized knowledge, its operation is often concentrated at one public data center in each of the federal states. This operating model can reduce redundancies and leverage synergies, an aspect that can generally be regarded as positive. It should be noted, however, that this approach significantly separates the recipient (Corner 3) from the reader (Corner 4), giving rise to challenges in the further implementation of data transmission in the OZG or e-government.
One of these challenges is a capability gap that at present is still frequently found as an element of the specialized procedures. In many cases, they are unsuccessful in establishing a direct connection to an OSCI intermediary and cannot collect their messages directly from the intermediary. In itself, this is not yet a problem because the recipient and the reader are also separated in the 4-corner model. In practice, however, no interface to OSCI that communicates directly with the recipient is integrated in the specialized procedures. Instead, it becomes necessary to set up yet another XTA server as an intermediary between the recipient and the reader, which collects the messages from the OSCI intermediary and forwards them to the specialized procedures as XTA2 messages. A sometimes open question in practice is where and by whom this XTA server can be operated.
At first glance, it seems to make sense to operate the receiving XTA server at a central location similarly to the OSCI intermediary and to connect the specialized procedures of the authorities as readers to it locally. De facto, however, there are implications that must be considered. The receiving XTA server decrypts the message it fetches from the OSCI intermediary. This process is not possible without access to the reader’s private key as the counterpart to the public key that is stored in the DVDV and that the sender used to encrypt the message. Under certain circumstances, it may be necessary at this point for a data processing contract to be concluded between the reading authority and the decrypting data center (as operator of the XTA server). In addition, the method for the transmission of the now decrypted XTA2 message must be clarified at this point. The encryption of the content during OSCI transport has been reversed once the message is fetched from the intermediary, and now a suitable transmission path for the messages that is as a minimum encrypted during transport between the recipient and the reader must be found.
The Federal Networks (NdB) should be used for this purpose, and indeed, their use during the XTA transmission is always expected. But challenges arise even here in practice. For example, the NdB are not designed for the transmission of really large data packets. This factor is becoming increasingly relevant for complex application procedures and administrative services, however. A good example of this is the processing of digital building permits; in North Rhine-Westphalia, for example, data sets as large as 250 MB are in planning today, and even larger volumes are assumed for the future.
One possible solution is the localized operation of XTA servers with direct access to the “readers” and their specialized procedures, i.e., the administration authorities. Brief consideration of municipal administrations, however, reveals that this approach cannot be implemented without any problems in practice. Municipal administrations in particular are often faced with severe staffing and budgetary restrictions. Such constraints pose major challenges for local governments when setting up and operating their own XTA servers, especially in federal states with a landscape of very small communities.
Ultimately, municipal associations, cooperative communities, and even the state CIOs as well, for example, have a duty to develop and implement operating models that are feasible under these conditions. Municipalities in particular must not be left alone to deal with these challenges as they often lack the requisite know-how and, in some cases, even the understanding of the related problems that would enable them to address these issues.
In this respect, mastering as quickly as possible the challenges entailed in the transmission of data when implementing the OZG and during the even broader digitalization of administration procedures as a whole is of urgent importance as the pace of implementation of the OZG is accelerating. A positive development in this sense is FITKO’s development of FIT-Connect, which is intended to view data dispatch holistically with a platform-based solution approach to networking and integrating IT systems in the federal IT architecture.
It remains to be seen how extensively this new standard will be implemented and how well it will be able to address both the problems described above and future challenges that are sure to arise.
