The Future of the Once-Only Principle in Europe

. The Single Digital Gateway Regulation (SDGR) and the underlying Once-Only Principle (OOP) outline that businesses and citizens in contact with public administrations have to provide data only once. The chapter gives an overview based on the ﬁndings of the EU-funded “The Once-Only Principle Project (TOOP)”. The authors summarise the developments related to the once-only principle and the SDGR in Europe. They also outline a vision for the future of the OOP in Europe. The vision is based on the analysis and the key take-aways from the previous chapters of this book. It also highlights the next steps to further improve the technical and legal basis and the chances given by the update of the eIDAS regulation. Furthermore, an opportunity for the sustainability of the OOP and the TOOP is described.


Introduction
Even if the Once-Only Principle (OOP) itself is not an entirely new approach the implantation of the OOP on a supra national level opens a new dimension. The OOP is among the seven underlying principles of the eGovernment Action Plan 2016-2020, as well as the Tallinn and the Berlin Declaration, to make government more effective and simpler and to reduce administrative burdens by asking citizens and companies to provide certain (standard) information to the public authorities only once. The implementation is based on the common need that was identified by most of the Member States and European Commission. The legal framework for this is the Single Digital Gateway Regulation (SDGR).

The Dimensions of the Once-Only-Principle
The previous chapters summarise the key aspects of the OOP in Europe. In general, the political, theoretical, legal, and technical foundations were analysed. Within this chapter, the main outcomes of this analysis will be highlighted. These are especially the major drivers and barriers, impacts and take-aways of good practices in Europe.

The Implementation of the Once-Only Principle on a National Level
This chapter focused on the analysis of the deployment of OOP at national level, as the EU-wide implementation of the OOP to a large extent depends on national administrations that serve as data providers and data consumers. Here the diversity of EU Member States in terms of national implementations of the OOP comes into play: different administrative structures, legal frameworks, IT systems, database models, as well as other elements, affect the deployment of the EU-wide OOP. This is further exacerbated by the different maturity levels of the implementation of the OOP at national level.
Analysis of the implementation of the OOP at national level revealed a number of benefits. Firstly, OOP puts user at the centre of the service, reducing the red tape, improving the efficiency and quality of public service provision. Secondly, OOP leads to the significant improvements in data quality, as no data is duplicated across different registries and therefore is easier to maintain. All this also leads to significant cost reductions for citizens, businesses and public administrations. Bringing the OOP to the European level will help magnify these benefits, advancing the creation of the Digital Single Market.
To bring this a step further, TOOP project explored and developed a generic OOP IT architecture, and tested and demonstrated it in three pilots focusing on general business mobility, eProcurement, and maritime transport, with the support of over the lifetime of the project more than 20 Member States and EEA countries 1 . The high-level architecture and the technical specifications that were developed by TOOP were taken up as a basis in the implementation of the Single Digital Gateway -the next milestone in the development of seamless cross-border digital services.

Drivers, Barriers and Opportunities
The drivers and barriers for OOP were analysed within different Member States and associated countries based on the experiences and findings within the TOOP project. Though there are some influencing factors that are more prevalent in one piloting area than another, mostly the drivers and barriers are similar across the TOOP use cases and would therefore suggest the same for wider implementation. Institutional factors were found to be the most influential -OOP implementation was perceived to be easier in Member States where the existing legal landscape was in favour of the principle and the political priorities of the member state aligned with the priorities of the TOOP project and vice versa in Member States where the regulatory landscape was less favourable of the OOP. The involvement of international regulatory bodies was also considered an important factor for successful implementation as the enforcement of wider adoption of the principle was considered crucial for reaching the full potential. Organisational factors such as the inherent structure and pre-existing procedures in the various organisations involved were found to be much less of a barrier than initially perceived at the beginning of the project.

Good Practices of Once-Only Principle Across Europe
To sum up the findings from the OOP good practice analysis, the investigation has evidenced existing good practice cases and enablers in different Member States. However, the diffusion of OOP solutions is still scarce, especially at cross-border levels of the OOP solutions. Further research and efforts from the side of government actors are needed to successfully implement the OOP across borders. The TOOP project provides a federated reference architecture for enabling the provision of OOP solutions across borders. However, as the analysis of good practices has shown, the success of the OOP implementation depends on many different enablers. Putting such enablers in place demands further considerable effort along a holistic perspective on public service design and implementation with the OOP.
Some further general insights from the good practice research: • While strategic policies in Europe extensively promote digitalization, networked systems and interoperability, digital transformation in practice and with the OOP as underlying paradigm is considerably lagging behind these visions. • While OOP visions are promoted to create awareness of the potentials and benefits, these activities are not necessarily reaching out to those that in the end have to implement the OOP solutions. • In particular, top-down implementation of digitalization needs to urgently be complemented with bottom-up engagement of relevant stakeholders by employing e.g., co-creation concepts, stakeholder engagement and similar to involve the relevant stakeholders in such digital transformations. • Attempts of bottom-up stakeholder engagement to realize interoperable cross-border public services need to be complemented with qualitative research to systematically and rigorously understand barriers and challenges of actors in digital public service provisioning and to design OOP solutions that meet the users' expectations.

Impact of the Once-Only Principle for Businesses Across Borders
The analysis of the impact has shown that it is unclear if the OOP fills a latent need and/or if the lack of an OOP is currently withholding companies to engage in crossborder business. Another point of attention is the connection to current legislation and existing building blocks: these connections need to become more explicit in the pursuit of a sustainability roadmap for Member States or sectors implementing the OOP. The OOP has a number of potential positive impacts, recognised by the pilots and their members. It is generally agreed among the research participants that most of the impacts will materialize shortly after the OOP is implemented. This however assumes that the OOP is successfully implemented among all business registries and in a critical mass of countries. Given that many Member States are currently arranging their regional and national data sharing processes and that this might imply some re-organization of registries and rights to share, the entire process will take a longer than initially foreseen. On the other hand, regulatory reforms such as the SDGR act as an accelerator for uptake by the Member States. The pace of implementation will differ per country and sector and also the readiness of some countries with regard to the implementation of some of the building blocks such as eIDAS, the European digital identity framework. The impacts of implementation of the OOP will differ per Member State and are dependent on factors such as digital maturity of the administration, social attitudes toward governmental data sharing, the local legal framework and perceived need for the service both within and outside the public administrations.

Managing a Large-Scale Pilot
Management of large-scale pilots is challenging for a number of reasons. First, largescale pilots are not typical research and innovation projects that are normally funded by the EU Framework Programme for Research and Innovation, and TOOP is also not a typical example of a large-scale pilot. The main reason for this is a very strong policy push and an expectation from the funding authority, and the community involved in the project, to deliver results. In classical research and innovation projects a certain probability of failure is tolerated, given the significant amount of uncertainty endemic to any research and innovation project. Hence, failure to reach some of the objectives set in the proposal is not necessarily interpreted as a failure of the project. Large-scale pilots operate at the boundary between innovation and deployment (TRL 8-9), and therefore bear a different level of expectations in terms of the certainty of project results. Most large-scale pilots operate in an environment with certain policy expectations and the results of such pilots often feed into the legislative process, in particular in defining secondary (technical) legislation, such as delegated or implementing acts. TOOP was designed and initiated in a similar environment in terms of the overall policy landscape, and with the expectation to eventually feed into the legislative process; however, with the push of the Estonian Presidency of the Council of the EU for the adoption of the Single Digital Gateway Regulation (SDGR), the expectations towards the project changed in the middle of the project's life cycle. With the adoption of the SDGR, the project was expected to not only feed into the development of the secondary legislation defining the technical requirements for the implementation of the SDGR, but also to develop the core technical components that would eventually support the implementation. This shift in perspective and expectations created additional pressure on the consortium and therefore also on the management of the project.
Second, large-scale pilots often involve a significantly larger number of participants than classical research projects. In addition to the number of participants, largescale pilots also involve diverse groups of participants, spanning academia, public sector organisations, and industry. It is therefore essential to strategically build the consortium already at the stage of designing the pilot to make sure the structure of the consortium will be balanced in terms of the overall objectives of the project, interests and capabilities of the participants, as well as expectations from the policy makers if the project is expected to support them. As mentioned elsewhere in this book, TOOP carried out three pilots with 19 Member States and associated country authorities. This allowed to develop and pilot solutions with a wide variety of use-cases and with a diverse set of national environments, ensuring that these solutions serve the ultimate goal of cross-domain information exchange.
Third, management of large-scale pilots requires a certain level of agility within a relatively complex environment. Considering that large-scale pilots involve a significant innovation component, agility is necessary in order to be able to respond to both changes in external environment as well as changes within the consortium, adapting the work of the project on the go, in order to make sure that the project achieves the set objectives on schedule, and on budget. The ability of the project to react, however, depends on one key factor -the funding programme and the specific requirements set for it.
As mentioned earlier, TOOP was supported by the Horizon 2020 Framework Programme. H2020 funding is mostly used for research and innovation projects, most of which fall below TRL7 (including), with the exception of pre-commercial and innovation procurement. In most cases, consortia involved in carrying out projects are relatively small and homogenous. As a result, the overall complexity of projects is rather limited. TOOP project, as a large-scale pilot, was very different in that sense. From the outset it had a two-tier structure of the consortium, with a number of sub-consortia at national level responsible for the implementation of the national pilots and other tasks. This two-tier structure was necessary to make the large consortium, consisting of around 50 partners, manageable, in particular when it comes to project governance and decision making.
Agility in the management of the TOOP project was achieved through a number of means, from the management of the development of the software components, to the management of the consortium, to the financial management of the project. Agility in the management of the consortium was necessary in order to allow for entry and exit of partners during the project. This allowed to maintain the consortium actively engaged in the work, in particular with the focus on piloting, and to introduce Member States and associated country authorities who couldn't join in the beginning of the project but were interested in piloting the TOOP solution. This also allowed to introduce the necessary competences that could not be identified at the beginning of the project.
With regard to financial management, to ensure tight control over partners' spending and maintain agility with regard to resource allocation, the project implemented an internal system of quarterly cost reporting. Reimbursements of costs for partners were based on their quarterly reports, which included also reporting on the work performed in the respective quarter. This allowed to ensure control of the project's resources, which is especially relevant in large consortia tasked with developing and piloting IT solutions. This approach diverges from the approach within classical Horizon 2020 research and innovation projects, where financial reporting is linked to periodic reporting defined by the funding authority (usually between 12-18 months). The more frequent financial reporting adds to administrative burden within the consortium and therefore puts additional pressure on the coordinator of the project.
First, the coordinator must ensure that a project management team is in place to oversee the overall governance of the project, internal financial reporting, as well as reporting towards the funding authority. Second, the coordinator must ensure that appropriate tools are in place to manage quarterly financial reporting in a way that is most convenient and efficient for all parties, and in particular to those who need to do the reporting. Last, but not least, the coordinator must ensure that the consortium agreement to regulate the operation of the consortium is fit for purpose.
Although the coordinator's project management team is essential for project's success in the long term, it is not sufficient, as many variables in the equation remain under control of the funding authority. First and foremost, the overall complexity of the Horizon 2020 grant agreement regulations requires a significant experience of the project management team within the specific funding framework to ensure that all rules and requirements are complied with, while at the same time ensuring fast action. Second, although the overall Horizon 2020 grant agreement framework is relatively flexible, the overall complexity makes it difficult to benefit from this flexibility. Third, it requires extensive coordination with the project officer from the funding authority to ensure efficient and effective project management.
To explain how this complexity plays out in practice, we provide an example. In TOOP project, consortium agreement foresaw the possibility to re-allocate funds on the basis of partner's contribution to the project in a dynamic way, using quarterly reporting as a reference point. For example, if one partner initially assigned to the task cannot perform the task, resources can be re-allocated to another partner who is willing and able to perform the task. While H2020 allows for such re-allocations in principle, when those are major and require re-allocation of responsibilities for tasks or work packages, these changes need to be implemented via an amendment to the grant agreement. If the consortium consists of ca. 50 partners, and in order to balance the project's budget, resource allocations for more than 50% of the partners involved may need to be changed. When these changes are combined with changes in the description of work, and some changes in the consortium structure (e.g., new or existing partner), and are implemented with one amendment request, the amendment request becomes very complex and therefore requires a significant time from the contracting authority to process and confirm. Often this requires corrections in the amendment request, which delays processing even further. In some cases, in particular in public administrations and publicly-funded universities, resources cannot be committed unless there is legal certainty regarding resource allocations. Hence, unless the amendment request is approved by the funding authority, some parties halt their involvement in certain tasks, thus affecting parts of or the entire project.
In the implementation of large-scale pilots, it is therefore essential to be aware of the limitations imposed by the specific funding instrument, and either choose a more flexible funding instrument (possibly with lower reimbursement rates), or plan ahead and incorporate long timelines for administrative procedures in the overall project plan.

Developing a Technical Architecture for a Large-Scale Pilot
As described above the number of partners and the technical involved are manifold. This causes one of the challenges for the development of a technical infrastructure for the OOP at a large scale. The chapter on TOOP Trust Architecture provided an overview of the Trust Architecture as an indispensable component for the implementation of the OOP in context of cross-border services spanning different policy domains. The Trust Architecture as devised in the TOOP Reference Architecture (TOOPRA) focuses on the trust establishment between the actors involved in an OOP System to provide guarantees on the origin, destination, authenticity (property that the entity providing the data is what it claims to be), trustworthiness (property that the entity providing the data can be relied on as honest or truthful), and integrity of information that is exchanged between the actors.
To overcome the main technical challenges in OOP application across the EU and associated countries -the diversity of organisations, procedures, data, and services on all four main levels of interoperability -the TOOPRA were developed. In the respective chapter about the TOOP OOP architecture it is explained, how this goal is achieved by using standard solution blocks, by designing the Reference Architecture and standard solution blocks in line with legal requirements, as well as by using tested, mature, interconnected and interoperable standards and building blocks. It relies on proven Enterprise Architecture methodology, ensuring consistent standards, methods, and communication among Enterprise Architecture professionals. The TOOPRA is a common outcome of the partners involved of TOOP pilots and the TOOP Solution Architecture.
The scenarios addressed by TOOPRA can involve organisations that could have no previous interaction; therefore, the preferred choice is trust by liability, possibly in conjunction with trust by reputation. The trust by liability is, in turn, supported by some existing general-purpose trust-enabling tools, such as: electronic identity, electronic delivery, and electronic signature or seal. These services are provided by Trust Service Providers and provide legal value. This particular architecture enables a community-based approach to digital trust, based on the existence of a network of trusted nodes (Access Points), which provide the capability to establish a secure and trusted channel between different public and private organizations. The Technology layer is complemented by the Organizational layer and the Legal layer, which provide a basis for collaboration between different entities, and ensure that the exchanged information maintains its meaning.
In order to facilitate the cross-border provision of digital services, in particular those based in the OOP, diffusion of mutually recognised electronic identification is key; however, history of successful use of different OOP systems is as essential for building trust of governments, organisations and users. In that sense, TOOPRA provides a solid set of tools for efficient deployment of OOP services and for the design of trust as an integral part of their architecture.

Piloting at Large-Scale
From the first ideas to change organisational structures within the European Union until the implementation into reality it was a long and partly stony way. Based on several experiences in the past, starting in the 90th of the last century, the EC has developed the approach of the so called "Large Scale Pilot" Projects (LSP). The LSPs became the instrument of the EC and the Member States to support the transition into a digital society. LSPs can be defined as goal driven initiatives that propose approaches to specific real-life societal, industrial challenges. Based on the point of view of the EC, pilots are autonomous entities that involve different kind of stakeholders from supply side to demand side, and contain all the technological and innovation elements, the tasks related to the use, application and deployment as well as the development, testing and integration activities. In 2001 the EC has declared it a priority for Europe to set up cross-border digital public services, allowing citizens and businesses from a Member State to interact with a public service in another Member State electronically.
First, Member States and the EC identified a few key domains where it would be very beneficial to develop common solutions at European level. Three topics were identified in 2005, eID, eProcurement and eHealth. As a next step, the areas of business set up and justice got a special focus. Within five dedicated LSPs technical solutions were developed. Besides that, also suggestions for organisational improvements were made. The outcomes of the LSPs were focussed on the specific sectors and not foreseen to be re-used or extended to other areas. Therefore, the EC and the Member States decided to design specific LPSs with a focus on a technical and organisational cross-sectoral interoperability. First, as part of the e-SENS project, based on generic and extensible technical building blocks cross-sectoral solutions were developed. As a second step, cross-border and cross-sectoral services were designed within the TOOP project.
The results of the LSPs are picked up by the EC and MS in manyfold ways. To support the sustainability of the technical building blocks that were developed especially by the LSPs, the Connecting Europe Facility (CEF) was set up. The goal of the CEF is to fund and support the development of the common infrastructure components. As continuation with the CEF2 program the EC and MS will support and catalyse investments in digital connectivity infrastructures of common interest. This will be complemented by further programs like e.g. the Digital Europe Program (DEP). The support is not limited to financial contributions, it is also possible to amend the legal framework.

Implementation of the Once-Only Principle
Many European countries have started implementing the once-only principle at a national level, while its cross-border implementation is still fragmented and limited to a few services. In view of its contribution to the realisation of the Digital Single Market in Europe, the European Commission is strongly promoting the implementation of the OOP across borders. Therefore, once-only is one of the underlying principles stated in the European Union's "eGovernment Action Plan 2016-2020" and is part of several initiatives related to the European Digital Single Market.
TOOP is concerned with the demonstration of this principle in the context of crossborder services for business and to support the transition towards the SDGR. It is the first large-scale pilot (LSP) project under the Horizon 2020 Framework Programme of the EU.
The TOOP project was launched on 1st of January 2017 and during its lifetime more than 50 organisations from more than 20 EU Member States and associated countries were involved. The main objective of TOOP was to explore and demonstrate the onceonly principle across borders, focusing on data from businesses via three distinct pilots. Via these pilots, TOOP wanted to enable better exchange of business-related data or documents with and between public administrations and reduce administrative burden for both businesses and public administrations.

ONCE-ONLY.ORG
Several initiatives around the OOP have started during the last years. These initiatives and projects are established in a national and supra-national context. Within these projects (e.g., TOOP), certain findings and results of a technical nature, including technical specifications and software components, have been developed. One of the main goals of the projects is to ensure that these important and potentially valuable outcomes are sustained, updated according to stakeholder requirements and available for use and exploitation, after the project's termination. They must also be maintained, i.e., to remain current e.g. in alignment with the specifications and architecture reflected into the SDG Implementing Act(s) and other relevant initiatives at EU level.
Therefore, the members of the TOOP project have endorsed ONCE-ONLY.ORG as organisation to sustain its results. ONCE-ONLY.ORG is an international not for profit association (AISBL -Association Internationale Sans But Lucratif) established under Belgian law, within the framework of the TOOP project, and as a part of its sustainability strategy. The purpose of the organisation is "to facilitate and promote international cooperation of public and private stakeholders aiming to advance and enhance the onceonly principle and other underlying principles for e-Governance and the interoperability solutions and practices that support them". Furthermore, its activities under the statutes may include actions that aim to "ensure the sustainability of state-of-the-art solutions, specifications, technological building blocks, and services, as well as related governance schemes and frameworks".
An AISBL is a member-driven organisation, it is an Association of Members. It is therefore open to all interested parties who want to continue being involved in the support of once-only solutions and more specifically to the sustainability of TOOP results. The membership of ONCE-ONLY.ORG is an excellent way to influencing their future, even if they are not among the current IPR owners. As members, all organisations will determine the future of the Association.
As such, ONCE-ONLY.ORG will be a viable sustainability organisation to accept the stewardship of the IPR pertaining to the OOP technical artefacts, to maintain and further develop them, and to make them available for the purposes of supporting European public policy, on the implementation of the OOP.

Update of eIDAS
The OOP and electronic identification of natural and legal entities are strongly interconnected. The setup of the regulation was a big step forward on the way to create a common legal basis for eIDs in the EU. But since the full entry into force of the eIDAS Regulation in September 2018, the implementation of digital identity even within the eIDAS framework is recognised as fragmented and not harmonized across the Member States. This leads into an interoperability issue.

Identity Matching
The databases used by the different administrations in the MS are mostly designed for specific cases or services. The underlying structure of the register quite often are set up before generic rules to exchange eIDs like in the eIDAS regulation were established. The data schemes are strongly related to the provided services. This causes a gap of attributes that allows an automated exchange of information and mapping of identities. Different information is collected about citizens and businesses and may identify people and organisation differently. To make it even more difficult, some Member States (e.g., Germany) do not have persistent identifiers or provide such persistent identifiers only as optional attributes. This causes a range of problems to match the identity of a legal or natural person already on a national but especially supranational level.
Record Matching Identification in Europe happens via eIDs notified under eIDAS. In this case, there is a record matching issue depending on MS infrastructure. While using notified eIDs under the eIDAS Regulation, for the most part will allow data providers to match an identity with a record (evidence requested) using the attributes of the natural person provided by the eIDAS minimum data set, in some cases additional attributes are needed to ensure a match. This is based on a lack of interoperability and the credentials defined in the eID schemes of the MS.
The lack of a match with the regulated electronic identity circuits falls under the national sovereignty, and the consequent lack of a sound legal basis. The revision of the eIDAS regulation is the opportunity to put a stronger emphasis on the capacity to reliably link notified eIDs to any corresponding identities issued for the same person in another Member State on the basis of that notified eID. The Commission currently appears to be contemplating the creation and management of unique European electronic identities (a secure European e-identity, as proposed by President von der Leyen), which would be available to European citizens upon their request and based on their notified eIDs. This approach may be suitable, especially if that unique European identity (or the accompanying infrastructure) can also be used as a tool to interlink national electronic identities that would be derived from a notified eID (or from the European unique identity that would also be derived from the original notified eID) (Schmidt et al. 2021).

Future for Large-Scale Piloting Such as TOOP and the Once-Only Principle as Such
The main goal related to the future of the Large-Scale Pilots is, to find a sound way to generalize, extend, and sustain the results of the project(s) and to deliver a proposal for the way forward for the LSPs itself. Besides that, it is of utmost importance to provide a proposal for the future of the Once-Only principle, as the OOP can be seen as the basis for any kind of cross-border and cross-sector data exchange. The means that it contains and can therefore highlight all pros and cons of the e-Government sector.
As highlighted within the chapters of this book, TOOP is part of a family of Large-Scale Pilots. One of the perceptions of the research is that TOOP is the end of the cycle of LSPs. Now, it is important to outline the way forward. Besides that, during the TOOP project and the previous LPSs several technical, organisational and even legal gaps were identified. The COVID-19 pandemic has speedup the related process of identification and has -like through a burning glass -put a strong focus on the outcomes. Various political and administrative barriers (such as data protection and data-sharing requirements, implementation costs, public sector silo issues, and especially legal barriers and/or gaps) that could hinder the actual implementation of cross-border initiatives were recognised.
The next steps have to contain a proposal for the sustainability of the outcomes of the TOOP project and to cover the gaps identified. One of the conclusions of the research and development within the project were that the goals set for the LSPs are reached. It can be assumed that piloting at a large scale is a proper instrument to bring together stakeholders, develop technical solutions and identify open issues. Based on this outcome, it worthwhile to propose a new cycle of LSPs that focus on and have a new thematic context. Furthermore, on the organisational side, it is important to continue the development related to the vertical networks. These networks like EUCARIS, BRIS etc. have to be sustained and extended into a wider context.
A logical next step would be to integrate the previously named vertical networks in the existing horizontal network set up by TOOP and to institutionalise its structures. This would be a step forward to use and strengthen the network. Thematically the network and future LSPs could focus on data ownership, data reorganisation and data responsibilities.

Conclusions and Future Research
TOOP has mastered an important challenge on the road to an integrated digitally transformed Europe by exploring, developing, demonstrating and piloting a pan-european data exchange layer that works. While it might have been just a first step where many are to follow: the paradigm that digital data should cross the border rather than physical paper evidence has shifted! But there still much to do, explore, learn and research, such as.
-How is trust established in digital for a cross-border Once-Only setting? -How to develop semantics for cross-border exchange further? -What is the actual impact of the cross-border data exchange applying the Once-Only Principle in real systems? -How could the TOOP data exchange layer be extended?
• How could a push scenario be realized? • How could the infrastructure be expanded using SSI, blockchain tech-nologies and architecture?
-How could a push scenario be realized? -How could the infrastructure be expanded using SSI, blockchain technologies and architecture? -How would the TOOP architecture look like if applied to other business sectors? -How can existing networks like BRIS, ESSIE, EUCARIS etc. be connected or even integrated into a TOOP style horizontal data exchange layer? -How can artificial intelligence help avoid fraud (e.g. amongst others through pattern detection)? -Etc.
These interesting research questions and challenges will drive our future research around OOP. Our next checkpoint will be the 2023 digital government research (dg.o) conference, which is due to take place in Tartu, Estonia. The conference topic will be "Cross-Border Digital Public Services". We should be able to see, how TOOP helped shape the this new kind of public service provisioning and European lifestyle -despite or even because of a Covid-19 induced contactless service delivery! Reference Schmidt, C., Krimmer, R., Lampoltshammer, T.J.: "When need becomes necessity" -The Single Digital Gateway Regulation and the Once-Only Principle from a European Point of View -forthcoming (2021) Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.