In Search of Smartness: The EU e-Justice Challenge

Abstract

At the EU level, an increasing number of resources are being invested in an attempt to provide better public services through the use of Information and Communication Technology (ICT). While new tools are being designed and implemented, a shift from ‘traditional’ technologies that must be used to provide services to more interactive ‘smart’ technologies is beginning to take place. At the same time, an adequate understanding of the implications of this shift is still missing. This paper focuses on the EU e-Justice experience with the ‘API-for-Justice’ project, which investigates the challenges of opening up the European e-Justice Digital Service Infrastructure to external service providers by means of Application Programming Interfaces (APIs). In particular, the exploration of potential services that can be provided by third parties through APIs for Justice shows the potential for a radical redesign of the justice service provision, where, for example, justice services are not requested by the party but are proposed or initiated by smart components of the infrastructure on the basis of inputs from the environment. In this perspective, smart technology research and, in particular, Brenner (2007)’s discussion on law and smart technology help to uncover the still unclear dynamics of change that characterize one of the key pillars of modern society: justice.

1. Introduction

All around the world, public and private resources are being invested in an attempt to provide more and better public services through the use of Information and Communication Technology (ICT) [1,2,3]. The use of ICT is seen as a means to “improve government efficiency through the reduced cost of electronic information management and communications, the reorganisation of government agencies and the reduction of administrative silos of information” [4]. It is also seen as a way to “reduce administrative burdens on citizens and businesses by making their interactions with public authorities faster, more convenient and less costly, thereby spurring competitiveness and economic growth” [4] Furthermore, “With many buzzwords such as electronic presence, e-auction, and accompanying stories of success, failure, and new business models from their counterparts in the commercial world… it is very difficult not to participate in the e-government movement” [1]. Such initiatives take place at the local, national, and international level, with increasing interdependencies between levels. While public administrations and policy makers play a key role in such development, the role of private providers is increasing in the service provision. Not only has “open data and collaboration with third parties has offered governments new insights into issues and possible new services” [4], but in a growing number of cases, public services provisions are becoming the result of complex networks of public and private actors and technologies.

Not everything is as easy as it may seem, though. Despite the many high-level political initiatives to sustain e-government, there are literature reports of unmanageable e-government initiatives and many experiences of development and implementation failure [1,5]. As the development and provision of public services through digital means grows, and technological possibilities broaden, public bodies are confronted with the need to ensure the use of new digital channels, not only in order to justify the costs sustained, but also to achieve the promised economies that e-services should grant.

One of the problems of the digitalization of public services, which has led to a limited uptake of the services by end users, is the shift of the burden of many administrative tasks from administrative personnel to the service user. It should be noted that this problem is not limited to the digitalization of services in the public sector. As we buy an airplane ticket on-line, for example, we fill in the data and do the checks that, off-line, were carried out by the travel agency. The increased burden is justified in the user perspective by the limited complexity of the procedure and by a number of advantages, including the reduction of costs for the ticket. Public administration procedures, on the other hand, often do not provide such advantages, since the complexity is much higher and the number of times in which a single user needs to carry out a specific procedure is more limited. The role played by civil servants in many cases is not just one of entering data, but also of explaining to the user the meaning of the specific parts of the procedure and the implications (and consequences) of their possible actions. As a result, service users are much more reluctant to use such services, in which they have to dedicate time and energy to learn procedures they will seldom use, with a higher risk of committing mistakes and no economic gain. One way to tackle this issue is through the use of multi-channel strategies, which aim to provide access to services through differentiated channels that are tailored to this type of user following a user-centric approach to “provide flexible and personalised ways of interacting with public administrations” [6]: namely, professional, repetitive users; inexperienced, non-repetitive users; and other specific categories of users. Another means to tackle this problem is to make services smarter, that is to say, to shift the burden of the service provision from the user of the services to the technology, or better, to the sociotechnical system providing it. This is becoming increasingly relevant not only at the national level, but also at the local level. It is no coincidence that “cities are increasingly aware of the concept of ‘smart city’ and actively developing strategies towards the goal of becoming ‘smart’ and manage, more efficiently, city resources and addressing development and inclusion challenges” [7].

While the shift from ‘traditional’ technologies and channels that must be used to provide services to multiple channels and more interactive ‘smart’ technologies is beginning to take place, an adequate understanding of the implications of what is happening is still missing [5,8]. An important step is being made to close this gap. This comes from the shift of scholars’ attention away from the technical development and features of smart services to the governance mechanisms that can support such developments and to the role that smart technologies can play in supporting such governance mechanisms [7,9].

This paper aims to contribute to the broader literature on Smart Government and Smart technologies investigating the problems faced when moving from a more traditional use of ICT in which the public administration provides electronic access to information, registration services (e.g., birth certificates), payment of fees (e.g., parking fees, fines, etc.), and e-health (e.g., appointments scheduling, on-line patient files, etc.) to a multichannel strategy in which the public administration infrastructure is opened to external service providers who can build smart(er) services. For this reason, the paper presents the case of the EU e-Justice experience carried out within the ‘API-for-Justice’ project, which investigates the challenges of opening up to external service providers the European e-Justice Digital Service Infrastructure by means of Application Programming Interfaces. In particular, the exploration of potential services that can be provided by third parties through APIs for Justice shows the potential for a radical redesign of the justice service provision. For example, there are situations in which the justice services are not requested by the party but are proposed or initiated by smart components of the infrastructure on the basis of inputs from the environment. In this perspective, smart technology research helps to uncover the still-unclear dynamics of change that characterize one of the key pillars of modern society: justice.

On the technical side, the focus of the ‘API-for-Justice’ project is to demonstrate the feasibility and the potential relevance of such APIs rather than to elaborate on specifications that are sufficiently detailed for direct implementation. The tailoring of the generic specifications elaborated by the project “to specific procedures (e.g., Small Claims, Payment Order) and user groups (e.g., consumers, legal professionals)” [10] is left to a follow-up project.

At the same time, the preliminary inquiry carried out within the project shows how the question is not only technical. The opening up of the European e-Justice Digital Service Infrastructure to smart applications developed by (private or public) third parties poses interesting challenges in terms of the governance structure and legal framework needed to govern the growing network of organizations and technologies providing smart services (this is further addressed in Section 4.3). While traditional justice service provisions are under the control of the court and follow the initiative of the parties, the new, smarter justice that will be enabled is the result of the action of—and is under the control of—multiple actors. More, the end user will increasingly delegate the initiative and the management of the procedure to the service provider and interact with the court in a mediated way, with a decreased awareness of what is taking place. Legal and organizational implications of this change have been explored in the API-for-Justice project, but will have to be carefully monitored also in the future through the testing and live experimentation of APIs for Justice and third party service provider initiatives.

The scope of this paper is broader than providing a gaze at the justice domain effort to provide smart services in the new global environment. While justice and justice service provisions are two key components of smart cities and key determinants for their governance [11], the API-for-Justice experience provides some interesting elements of reflection on the quest for smartness. The paper provides relevant inputs on how the development of Smart Services for public administrations and cities by third parties (be they private or public) can be enabled and on how the governance of smart cities and their development can be supported. Finally, it draws attention to the legal, organizational, and social aspects that need to be monitored, as our understanding is still fragmented and our interpretations are often based on ‘dumb’ theoretical frameworks that are not capable of grasping the ‘smart’ system implications.

2. Materials and Methods

The API-for-Justice case study has been carried out following a multidisciplinary research approach which mixes social science theories, methods and tools with the legal as well as the information and communication ones [11,12]. This multi-disciplinarity approach promotes understanding of the multi-domain nature of the phenomena under observation, which are the result of the interaction of technological, legal, and social components within complex and evolving governance frameworks.

Furthermore, the case study approach has been shown to be a quite effective method for studying the ICT phenomena, especially in the area of justice [13,14]. Case studies are especially suitable, as a general understanding of the phenomena is sought, while the researcher/author has limited control over events, and the focus is on a contemporary phenomenon within a real-life context [15].

In addition to the analysis of the project documentation and the formal and informal interviews with the key participants of the project, the author has been involved in the project as a participant observer [16] and as an action researcher [17,18]. The action research approach allows the overcoming of “the deficiencies of positivist science for generating knowledge for use in solving problems that members of organizations face” [19]. In Rapoport’s definition, “Action research aims to contribute both to the practical concerns of people in an immediate problematic situation and to the goals of social science by joint collaboration within a mutually acceptable ethical framework” [20]. In other words, its purpose is “both changing the system and generating critical knowledge about it” [19]. Successful innovative efforts result in the breaking of stable organizational settings, in which the meanings of routines and actions are well understood on the basis of previous experiences. The objective becomes generating workable solutions that are contingent, uncertain, and in an emergent context. In this context, action research “contributes to the development of theory by taking actions guided by theory and evaluating their consequences for the problems members of organizations face. Theory may then be supported or revised on the basis of the evaluation” [19]. According to Rapoport, “there are advantages and disadvantages from a purely scientific point of view of getting oneself involved in a helping role within the very system one is studying: on the one hand one sacrifices a degree of detachment and independence (perhaps impossible because of the situation anyway) but on the other, one may gain a sense of sympathy and identification which may produce more valid information than what might have been gathered from a more detached vantage point (Sofer, 1961). This may not be only a qualitative issue, but one of gaining any access. The ‘cold’ scientist might not be allowed to penetrate the system at all (Trist et al., 1963)” [20].

Within the API-for-Justice project, the author has been the coordinator of the project team carrying out the analysis of the legal prerequisites and conditions for the development of a multi-channel strategy for the delivery of e-Justice services based on APIs, and he has been working to identify and explore possible cross-border judicial services that could be provided with the support of APIs. He has actively participated in the project proposal preparation, key meetings and discussion, report and recommendations drafting, and other initiatives. By bringing the observer within the object of observation and making him part of the ongoing actions, this method has provided a privileged view [21] and allowed a “much deeper understanding of the on-going phenomenon” [11]. The action researcher perspective and the reflective interaction with the project participants allowed the investigation of the emerging judicial context and the challenges which will be generated by the introduction of APIs and third parties APPs in the justice domain service provision when combining the researchers’ and practitioners’ competences and skills. These kinds of interactions took place through structured project meetings, in which domain experts with various backgrounds (ICT, law, etc.) were brought together to discuss key topics, identify issues, and address them both in other less structured communication exchanges, such as e-mail exchanges and project documents’ drafting and revision. In these exchanges, the author contributed to the project with his social scientist and e-justice competences but at the same time collected data on the process itself to allow for the reconstruction of the ongoing actions. Furthermore, during and after the project the researcher had several individual exchanges, between half and one hour length on the average, with the project coordinator and key contributors, discussing the project and its development, presenting insights resulting from the observations of the project activities, and engaging in confrontations over them. It should be noted that APIs have not been developed by a third party during the project, and that the challenges so far identified resulted from the organizational, legal, and technical analysis and from the process modeling and theoretical prototype design activities carried out during the project. While a follow up project is planned to develop a 'proof of concept' with the purpose of investigating potentials and challenges in a real life situation, an API prototype specific for Greek lawyer software providers is also being developed (and studied by the researcher) in another EU funded project called Pro-CODEX [22].

3. Theoretical Framework

In recent years, increasing attention has been given to smart technologies and more in general to the use of information and communication technologies to provide ‘smart’ services by public administrations at the national and local level. Researchers have focused on several aspects of this phenomenon from the technological component (techno-centered approach) to the human and social component (human-centered approach) to the service provision (user-centered approach) [23]. From democratic participation to public administration, the governance of smart services provision and the infrastructural dimension enabling smart services provision have also been investigated. Each of these elements is relevant for the understanding of the smart service provision dynamics, but provides only a partial perspective.

The work carried out by Meijer and Rodríguez Bolívar’s review of the literature on smart urban governance [24] provides a unifying perspective, suggesting the need to consider the sociotechnical nature of the phenomenon, combining technical, social, and governance perspectives. More specifically, they identify three broad definitions of smart cities: “smart cities as cities using smart technologies (technological focus), smart cities as cities with smart people (human resource focus) and smart cities as cities with smart collaboration (governance focus)” [24]. On the basis of their literature review and “building on the work of Fountain (2001) and Orlikowski (1992), the authors suggest the need to adopt a sociotechnical perspective to investigate the dynamics of smart cities, which are composed of technological, human and governance components” [11]. Considering this framework and building on its experience in the justice domain, Velicogna suggests extending it to include the legal dimension. The author argues that “Laws and other normative instruments, while not easily visible looking at the socio-material complexities of smart information systems, are inscribed and regulate the use of technologies but also shape the actions the human and governance components of the smart cities” [11]. Furthermore, smart cities and services are built on infrastructural components that are not just technological, but also organizational, legal, and of a governance nature, which must be also investigated to create a comprehensive understanding of the phenomenon [11].

Brenner [25], discussing the problems faced by legal framework designed to regulate the use of traditional technologies when confronted with smart technology, provides the final element needed to complete the framework. Brenner underlines “how the traditional relationship between law and technology must evolve to accommodate a fundamental shift in the nature of technology” [25], a shift which takes place when technology becomes smart. According to Brenner, the critical change that takes place is in our relationship with the technology, which shifts “from ‘using’ technology to ‘interacting’ with technology” [25]. This poses a problem because “Our history to date with technology has been one of ‘use’—an active, intelligent human being ‘uses’ passive, ‘dumb’ technology (a simple tool or mechanical device). Though many of these technologies are functionally complex, they operate only at the will of a human being” [25]. At present, though, with technology becoming smarter and absorbing more and more of the complexity and understanding of the procedure, “we are on the threshold of developing a new dynamic—one that will involve ‘interaction’ rather than ‘use’.” [25] Smart technologies differ from the technologies we are used to in the sense that “‘smart’ technologies are capable of acting on their own. They can therefore work with us by anticipating our needs and fulfilling them; they can also replace us by taking over certain tasks, such as operating motor vehicles. The second difference is that ‘smart’ technologies are meant to be, and will be, unobtrusive; as noted above, they will fade into the background and disappear from our awareness. This is why they are commonly referred to as ‘ambient’ technologies” [25].

4. API-for-Justice Project

API-for-Justice is an EU, co-funded project, running from January 2016 till June 2017. It is coordinated by the Dutch Ministry of Justice and includes as partners the Aristotle University of Thessaloniki, the Research Institute on Judicial Systems of the Research Council of Italy, the Federal Ministry of Justice Austria, and the Ministry of Justice of North-Rhine Westphalia, comprising a total of five countries involved. It investigated the challenges of opening up the European e-Justice Digital Service Infrastructure and the European e-Justice portal by means of Application Programming Interfaces (APIs). But what is an API? The Merriam-Webster dictionary defines an API as “a set of rules that allows programmers to develop software for a particular operating system without having to be completely familiar with that operating system” [26]. Wikipedia provides a more extensive definition, describing an API as “a set of subroutine definitions, protocols, and tools for building application software.… Just as a graphical user interface makes it easier for people to use programs, application programming interfaces make it easier for developers to use certain technologies in building applications. By abstracting the underlying implementation and only exposing objects or actions the developer needs, an API simplifies programming” [27]. For the API-for-Justice, “An Application Programming Interface (API) is a technical contract that information systems use to encapsulate functionality that can be used in an automated fashion by another system. APIs are widely used when engineering information systems of any type. APIs enable the ‘using system’ to be unaware of the actual implementation of the system that offers the API. In this sense, APIs allow both systems to change and evolve more or less independently, as long as both respect the technical contract” ” [10].

While all three definitions provided describe APIs as technical objects, which indeed they are, most of the complexity of opening up the European e-Justice infrastructure to third party digital service providers appears to be of legal and governance nature. The legal and governance elements are present in most APIs, as “in addition to the technical contract (the system-system interface), use of APIs often entails the use of legal contracts between provider and user of the API that cover legal, liability, financial, organisational and other aspects” [10]. Nevertheless, the point is much more relevant in the justice domain, where not just economic interests but also key values of the society are at stake. As an example, trust in the justice system is not just a question of legal liability for the service provision in which third party providers are allowed.

4.1. Justice Systems, EU Cross-Border Justice Service Provision, and EU e-Justice

Some background elements of justice systems such as the EU cross-border justice service provision and EU e-Justice can be useful for putting the API-for-Justice project into perspective. “Justice systems have been traditionally designed as highly structured and regulated systems, characterized by high level of formality, where standardized procedures and practices are designed to support and uphold the Law (and its liturgy) through the justice service provision” [28]. In this context, the main features of justice service provision have remained unchanged for over 200 years. In the last 30 years, though, something has changed. ICT has been introduced in the justice domain, gaining an increasingly wide foothold [29,30,31]. Paper-based procedure and practices have been translated into digital, from the creation of electronic court registers, to the development of electronic case-management systems, to the dematerialization of court documents and communication exchange [14,32,33]. While potentially revolutionizing, this translation has taken place in most cases without broad reconfigurations in the roles of key actors or of key procedures behind the service provision. Technology, even when successfully introduced, has been typically conceived as a tool to support the digitalization of paper-based components and practices, attempting to create digital analogues in order to improve efficiency of record keeping and communication between the traditional actors (judges, lawyers, parties, etc.) [14,32,34]. Furthermore, where changes have taken place, they have often occurred within the traditional institutional framework, with piecemeal mutual adaptations between laws, procedures, organizations, and technologies [33,34]. At the same time, the increasing movement of people and goods, the dematerialization of services and practices, and the growing role of ICT and smart technologies in people’s everyday lives are increasingly challenging the organizational arrangements of traditional (and even electronically enhanced) justice service provision [34].

EU cross-border justice is a key area where such challenge is becoming evident. “The creation of a European common market and the free circulation of goods, services and people have increased the relevance of having faster, simpler and cheaper cross-border judicial procedures, of ensuring a high level of security and judicial cooperation in criminal matters, of supporting access to justice and ensuring the right to litigation in civil matters” [12]. To this end, the European Union adopted several directives, regulations, and other legal instruments to harmonize procedures and support cooperation in the criminal and civil justice areas, such as the European Arrest Warrant [35], the European Investigation Order [36], the European Payment Order [37], the European Small Claim Procedure [38], the Service of Documents in civil or commercial matters [39], and the European Account Preservation Order [40]. Despite the intention of the European legislator, cross-border judicial procedures remain quite complex. This is especially true in civil matters, as procedures in theory intended for pro-se litigation have been recognized as being too complex for non-legal professional users [41] and requiring specialization, even for legal professionals (see, for example, Steigenga et al. [10] and Kramer [42]). It should not be a surprise that the number of cross-border judicial cases is quite low and not comparable with the expected need of the judicial resolution of cross-border matters.

An attempt to improve the situation has focused on the development of e-Justice and digitalizing cross-border procedures. The e-justice, as a means to support cross border service provision “has been on the agenda of the EU policy maker for over a decade.” [42] In the European Union, e-Justice is conceived of as a tool for providing information to legal professionals, EU citizens, and businesses, and for supporting cross-border access to justice. According to the API-for-Justice Project description and implementation document, “effective digital access to cross-border legal procedures is essential for improvement of the European internal market” [43].

Two key implementations have been developed: the European e-Justice Portal and the European e-Justice Digital Service Infrastructure. The European e-Justice Portal has been developed by DG Justice and is supported by the Member States and key justice stakeholders. The portal is intended to be “a future electronic one-stop-shop in the area of justice” [44]. The European e-Justice Digital Service Infrastructure, developed by a large consortium including 22 Ministries of Justice or their representatives and co-funded by the EU in a project called e-CODEX (e-Justice Communication via Online Data Exchange; https://www.e-codex.eu), is an infrastructure created to support a legally valid communication and exchange of legal information in EU cross-border judicial procedures. Due to the principle of subsidiarity and already existing national systems, the infrastructure has been developed as a system to make an existing national solution interoperable. In addition to secure transportation, it deals with electronic identification, signatures, and semantic interoperability [11,45]. An e-CODEX technical solution was then consolidated in a follow up multi-domain (e-Justice, e-Health, e-Procurement, etc.) project called e-SENS (Electronic Simple European Networked Services; https://www.esens.eu/), whose aim was “to provide the foundation for a platform of ‘core services’ for the eGovernment cross-border digital infrastructure foreseen in the regulation for implementing the Connecting Europe Facility (CEF)” [46]. Within the e-SENS project, the e-Justice domain team also worked on the attempt to extend the number of procedures available to end users through the infrastructure [47]. While both the European e-Justice Portal and the European e-Justice Digital Service Infrastructure are operational and a number of services are provided, these systems have by themselves been so far insufficient to make an EU cross-border judicial procedure sufficiently accessible to attract a large mass of users [12,28]. The CEF ‘CEF-TC-2017-1: European e-Justice Portal’ call for a proposal can be seen as an attempt to address the problem, encouraging “the further development and connection of services to the existing modules of the European e-Justice Portal” [48] and, in particular, supporting Member States’ wishes to join “the e-CODEX judicial workflows operated in the context of the European e-Justice Portal or cross-border initiatives associated with it” [49].

The API-for-Justice project can be seen as a different attempt to address this problem, opening up the system to third parties that can support the EU cross-border justice service provision. From this perspective, one of the main aims of the project is to investigate how to “enhance the e-CODEX platform with an interface for alternative entry points for cross-border legal procedures. An alternative entry point could—for example—be an online dispute resolution centre to support consumers in dealing with a specific type of dispute” [43]. This objective is in line with the EC multi-channel strategy included in the Ministerial Declaration on e-Government approved unanimously in Malmö on 18 November 2009, according to which public services to citizens and organizations must be usable via different channels, both electronic and non-electronic [50], with the Ministerial declaration on e-Government to be approved in Tallinn on 6 October 2017, according to which “public services should be available digitally as the preferred option,… citizens and businesses should be asked to submit any information to a public administration only once, … public administrations open up to and engage with stakeholders to innovate and co-create service design and delivery, … public services and IT systems should work seamlessly across organisations and platforms, also across the Single Market and beyond” [51].

In order to open up the system to third parties, the project needs “to clarify the legal constraints for the connection of the e-CODEX platform with applications from Member States, European Institutions or third parties and to develop the technical specifications of such an interface” [43].

4.2. The Project Organization and Main Tasks

The project was organized into four working units. The first unit dedicated to project management and project support took care of the overall planning, the monitoring of the results, risk management, budget administration, and the communication/marketing initiatives.

A second working unit was dedicated to the analysis of the legal prerequisites and conditions for the multi-channel strategy. This work was done taking into account the results of previous Large Scale EU projects such as STORK (Secure idenTity acrOss boRders linked; http://www.eid-stork.eu), e-CODEX, and e-SENS [47], as well as the new e-IDAS regulation. Much effort was dedicated to the clarification of the legal constraints, for both the API themselves and for their deployment by Member States, institutions, and third parties. The activity was carried out taking into consideration the existing actor, coordination mechanisms, legal framework, and procedures involved, as well as the new ones, which could be involved or required by the opening up of the infrastructure. The unit developed two questionnaires to investigate the practical implementation of two key cross-border procedures in the EU Member States: a questionnaire on the practical application in Member States of Regulation (EC) No 861/2007 of the European Parliament and of the Council of 11 July 2007, establishing a European Small Claims Procedure; and a questionnaire on matrimonial matters’ and norms (divorce, legal separation, annulment, and update of civil status record) and the application of Regulation (EC) No 2201/2003 (Brussels II). The purpose of the questionnaires was to investigate the significant divergence in national practices with reference to the application of the EU procedures, which potentially affect the development of APIs and the implementation of applications dedicated to third parties (the interaction between EU procedural rules and national procedural rules leads to a diversity of approaches and complexities for the user of ‘simplified’ cross border judicial procedures, who is likely expecting to have to deal with something simple [52,53]). The questionnaires were administered through the Multi-Channel Strategy Working Group of the Council of the EU. Replies to the questionnaires were provided by the representatives of the Member States participating in the Working Group. The analysis of the information collected allowed us to identify several elements of national variations of EU procedures which manifest themselves as complexities, to be furthermore addressed in the use of the case legal analysis of the end-to-end processes [10].

A third working unit was dedicated to the identification and description of the technical options for API within the context of the European Interoperability Framework, e-Justice Portal, and e-CODEX infrastructure. The technical options had to match the legal preconditions identified in the second working unit. Its objectives included the development and documentation of the technical specifications for an API-for-Justice.

The fourth and last working unit was dedicated to the identification and exploration of use cases (in a process modeling context, a ‘use case’ generally is intended as a textual or graphical representation describing the steps of the interaction between an actor and a system to achieve a certain objective). This included the development of criteria to identify cross border legal procedures which could be supported, the identification of use cases which will benefit most from this multi-channel approach, and of tools to match API technical specifications to the most benefiting use cases. One of the key efforts of the working unit was to shift the focus from the cross-border judicial procedures that had characterized the e-CODEX initiative to services a potential user may need to solve his/her legal problem or dispute, thereby closing the gap that exists between the technical and legal instruments provided by the e-CODEX and the EU e-Justice Portal to create usable instruments. The problem is that “The user often does not know which steps should be taken before starting a legal procedure, which procedure could be used (if one or more than one is available), or how the chosen procedure should be carried out. Non-repetitive users, in particular, do not have the practical knowledge needed to overcome the problems emerging in the attempt to use a cross-border legal instrument and to deal with the specificities of the National Judicial systems procedures to which the EU regulation delegates the actual implementation of the service” [10]. In the perspective of the API-for-Justice project, the burden of this complexity can be shifted to ‘smart’ combinations of intermediary technology and organizations enabled by APIs and available to the end user through APPs developed by (public or private) third parties.

To achieve this objective, the working unit developed a methodology to “investigate and evaluate the potential to develop APIs and to support existing cross-border judicial procedures. This approach builds on the experience developed within the e-CODEX project for the identification and selection of use cases and further explores the processes and procedures involved not only through the use case oriented business process analysis, but also by taking the user perspective in relation to the justice service provision. The approach exploits user stories emerging from the empirical analysis of the selected procedures and describing present, and potential future uses, highlighting problems and potential solutions, which may be addressed through ICT tools” [10]. Each user story presents two narratives: one portraying the current situation, in which existing facilities are used and their problems from the user perspective are shown; and a second one describing a possible future situation in which an API is used to communicate through the e-CODEX infrastructure and with the EU e-Justice Portal.

The user stories allow a representation of the process that can be presented to third parties. They also provide a reflective tool presenting the procedure from the end-user perspective, allowing for the highlighting of the key steps that an API is to support. Figure 1 presents the swimming lanes describing the main business transactions for a user obtaining information about a generic procedure and identifying the authority to contact through an EU API and the European e-Justice Portal while proceeding to file a request to the National Authority. This model is based on one of the project user stories.

Each step is then analyzed in detail considering goals, initial and end conditions, and data and documents flow. “A Business Use Case means a business opportunity with an end goal being pursued through the incorporation of one or more e-Justice Use Cases (such as Find a Competent Court, Find a Lawyer, European Order for Payment procedure, European Small Claim Procedure etc.). Such service-level use cases may serve more than one business or set of business goals. For example, ‘Find a Competent Court’ and ‘Find a Lawyer’ use cases are supporting several business use cases incorporating cross-border e-Justice use cases” [10]. At the same time, “different use cases and EU and national regulations may impose different requirements for third parties providing cross-border e-Justice services” [10].

As an example, the ‘Rent-a-car’ APP developed by a third party may include support functionality in case the end user has a problem with a renting agency. This solution may include access to Online Dispute Resolution but also support the user in identifying the legal means available, and in some cases in the filing and managing the claim. The APP could, for example, on the basis of the information already available about the user and renting, suggest that a European Small Claims Procedure could be started, and through an API that allows access to the European Court Database (which is currently available only through the e-Justice portal using a user interface), find the competent court and prefill a European Small Claims Procedure Claim Form (Form A) in one of the languages accepted by the competent court. Once completed and electronically signed, the APP could then submit the Claim Form through an API to the e-CODEX infrastructure and to the competent court, receive formal communications from the court, and allow queries on the status of the procedure.

Here is a description of the steps that take place in the interaction between the third-party application (the ‘Rent-a-car’ APP) and the API (adapted form [10] during the initial filing of the case: 1. The third-party application sets up a technical connection to the API; 2. The API authenticates the system that sets up the connection, based on its TLS-certificate. The API only allows the connection if the system is authentic and registered (known to the API); 3. The API receives the technical input message and validates it. Part of this validation is a validation of the electronic signature. This must be the signature of a registered third-party service provider; 4. The API constructs a message conform to the e-CODEX specifications. This message contains the user form; 5. The API sends this message to the competent authority (the competent court) using the e-CODEX gateway to which it is connected; 6. The API generates a unique ‘Transaction ID’ and keeps this in its internal state table, together with the ‘Competent Authority ID’; 7. The API returns the ‘Transaction ID’ to the calling application.

According to the API-for-Justice project, there are no major technical obstacles for implementing an API such as the one mentioned in the example before based on the European Small Claim Procedure or the one investigated for the detailed analysis and based on the EOP procedure in the project itself “once the eIDAS Regulation has been implemented by the Member States (in September 2018)” [10].

The critical issues that have been identified and need to be addressed concern [10]:

1

Business potential: How many service providers are potentially interested in offering services based on an API? Related to this question, what is the number of procedures that competent authorities can expect when such services become available more widely?

2

Legal: What is the legal framework for an API?

3

Governance: What is a suitable governance model for such an API, which takes into account the interests of all stakeholders?

4.3. The Governance and Legal Framework

The analysis of the existing governance structure and the inputs originate in another EU project that studied the problems related to the opening up of the e-CODEX infrastructure for legal professionals using their legal software (Pro-CODEX). This led to a reflection on the limits of “the current governance of the e-Justice Digital Service Infrastructure and identifies the general legal prerequisites and conditions for enabling third-party access to e-Justice DSI services” [10] “Existing mechanisms for the establishment of trust relations that enable the provision of e-CODEX services may not be adequate to support the new ones needed to allow third parties service providers to connect to and leverage on the e-CODEX infrastructure in order to act as a usage multiplier” [11].

In the pre-API system, the main actors involved in the EU cross-border justice service provision are institutional players, such as Ministries of Justice, the Courts, etc. Their interactions and behavior take place within the framework of judicial cooperation between EU Member States and EU Judiciaries. Opening up the existing infrastructure to third party justice service providers can lead to “issues such as liability, intellectual property, intermediation and malpractice in the digital mediated services need to be considered. Additional requirements may be imposed on the basis of the opportunity to protect court users in the electronic environment” [10].

As a consequence, existing trust relationships need to be discussed “and new trust relationships … need be established” [10]. To this end, the API-for Justice project developed a governance model intended to “ensure that the trust established between the current parties involved in the provision of cross-border e-Justice services, i.e., the European Commission and the EU Member States is maintained through appropriate extensions when access to the e-Justice infrastructure is provided through alternative channels” [10].

In line with the complexity of the system, the API-for-Justice project proposes a multilevel governance structure defining roles, competences, and relations between the key actors and stakeholders. The governance structure was designed following CEF definitions (i.e., definitions developed by the Connecting Europe Facility (CEF) of the European Commission) not only to be organizationally functional, but also to include the requirements of the eIDAS Regulation. The work carried out within the e-SENS project concerning the European IT governance structure has also been taken into consideration in the process [54,55,56]. The model should “ensure that the trust established between the current parties involved in the provision of cross-border e-Justice services, i.e., the European Commission and Member States is maintained through appropriate extensions when access to the e-Justice infrastructure is provided through alternative channels” [10].

According to the API-for-Justice project, “The APIs opening up the e-CODEX infrastructure should be developed, updated under the supervision of the e-CODEX infrastructure policy owners (identified as the Member States—Ministries of Justice, and the Commission—DG Justice) and made available to the institution maintaining the infrastructural components (i.e., e-CODEX Gateways and Connectors). Through the institution maintaining the infrastructural components, the APIs services should than be made available to external service providers. This would allow the service providers to connect their applications to the e-CODEX Infrastructure” [11]. The API-for Justice-project underlined how legal and technical obligations for API Providers and Service Providers needs to be set up in Interoperability Agreements based on the principles set by the e-CODEX infrastructure policy owners. “Such Agreements will be necessary to detail obligations, responsibilities in relation to the service provision and accountability of the parties” [10]. Legal obligations do not depend just on the parties and on the principles set by the e-CODEX infrastructure policy owners but have to comply with the EU and national legal frameworks. The General Data Protection Regulation, for example, when becoming applicable on May 25, 2018, will provide a uniform regulatory framework for all Member States in relation to Security, Privacy, and Data Protection.

Figure 2 provides a representation of the governance structure suggested by the API-for-Justice project, including key actors and existing and new trust relationships that need to be established to support API-for-Justice. On the right is the e-Justice Digital Service Infrastructure (DSI) governance components, which include the e-Justice DSI Owners and the e-Justice DSI service provider. The Solution Provider of the e-Justice Digital Service Infrastructure is the organization taking care of the maintenance and the updating of the generic components of the infrastructure. The process of designating the e-Justice DSI Solution Provider is still not completed. This task is presently being handed over from the e-CODEX partners to the European Agency (EU-LISA) through a Me-CODEX project. The Owners of the e-Justice Digital Service Infrastructure are the Member States and the European Commission according to their area of responsibility. They are accountable for the policy side of the DSI, through the EU-level e-Justice policy bodies, as well as the functional side of the DSI. National implementations of the generic components of the infrastructure (e-CODEX gateways between national infrastructures to the core service platforms and connectors that link the gateways to the national e-Justice infrastructure) are managed at a national level. This part of the DSI is managed, implemented, and operated by the Member States. A trust relation (represented by the blue arrow) is supported by an interoperability agreement (which regulates the obligations of the parties involved in the maintenance and update of the generic components of the infrastructure and the national authorities implementing them).

Near to the e-Justice Digital Service Infrastructure (DSI) governance components are the APIs governance ones. According to the API-for-Justice team, “The API-for-Justice Provider is expected to be the same as or closely associated to the DSI Solution Provider, as the API will need to follow closely the updates and change management if the DSI. Therefore, the API is regarded as an extension of the DSI infrastructure itself to accommodate additional access channels” [10]. Furthermore, “it is envisaged that the API-for-Justice would be an extension of the e-Justice DSI reference implementation and will be updated accordingly. As such, the API and its updates could be made available by the DSI solution provider to the DSI owners” [10].

The third party digital service providers (private and public), which develop APPs to provide services to the end users, are defined as Value Added Service Providers (VASP). Interoperability agreements need to be set up between third party digital service providers, the API-for-Justice Providers, and the API-for-Justice owners based on the principles set by the DSI owners. From this perspective there is therefore a need “to define Guidelines, derived from the common principles and agreements in the e-Justice domain at EU level, for Member States to apply when deciding on providing access to their national cross-border e-Justice Infrastructure to parties outside their immediate supervision, as well as for a certification framework of such parties and apps” [10].

Underpinning the governance structure of the operational components of the e-Justice DSI, APIs and third party digital service provision is the policy layer, which falls under the coordinated competence of the Member States (Ministries of Justice) and the European Commission (DG Justice). The policy layer should allow third party digital service providers to input their requirements while at the same time providing supervision of the impact that opening up of the service provision to third parties has had on the justice service.

Within this Governance Model, API implementations can be deployed in a number of ways [10]:

1

The Centralized (EU) Model: A central authority deploys a single instance of an API and, in this instance, accesses the trust network through a dedicated interface at the EU level. DG Justice could manage the central deployment (connecting to the EU e-Justice Portal or the e-CODEX infrastructure), but another central authority could take care of it (e.g., one assigned by the Member State). One important condition is the possibility for the authority to access the e-CODEX trust network. Third party digital service providers should only access the central instance of the API. This model supports uniform governance of the API. All service providers and implementations are done once, centrally, instead of multiple times in several Member States.

2

The Decentralized Member State Model: Member States deploy their own instance of an API, and each one of these instances accesses the trust network through the national connector. Third party digital service providers access API-instance(s) in one or more Member States. This model can allow for more flexibility, for instance when certain Member States are deploying specific bilateral use-cases for a procedure in which they would like an additional channel. It may allow Member States that decided to adopt earlier, such APIs, to influence the pace of the adoption of specific procedures. Therefore, it is more complex to govern, namely, to enforce uniform terms and conditions for third-party service providers, and to enforce the uniform supervision of these service providers.

3

Hybrid model: A combination of the above two models.

The research carried out within the API-for-Justice project demonstrated that “that the realisation of an API-for-Justice is both useful and feasible in the longer term; however, a number of open issues must be addressed” [10]. Recognizing the socio-technical, legal, and governance complexity of the initiative, the project team suggested following an incremental approach: “A stepwise approach for the implementation, with intermittent piloting activities, is recommended. For example, the API may focus in the first instance on guidance and user support in carrying out electronic procedures, then functionality may be extended to support the electronic legal processes and communication as a pilot application of the API will allow for an in-depth understanding of the governance, legal and implementation challenges” [10].

Furthermore, when opening up the existing infrastructure, a clear definition of roles for ownership, provision, implementation, maintenance, and client relationship management become much more critical than when the system is still closed. Mechanisms to ensure trust, accountability, and governance in the much broader network of organizational and technological components need to be established. While the existing legal framework may provide both some guidance and identify necessary requirements, this is not sufficient. In some cases soft law solutions may be found. As an example, “Guidelines should be derived from the common principles and agreements in the e-Justice domain at EU level, for MS (Member States) to apply when deciding on providing access to their national cross-border e-Justice Infrastructure to parties outside their immediate supervision, as well as for a certification framework for such parties and Apps” [10]. At the same time, given the fragmented nature of the legal framework, a legal analysis to determine the legal basis for the services to be enabled and their delivery needs to be carried out on a case-by-case basis. Furthermore, given the limited predictability of the reconfiguration potential of third party service providers’ initiatives, on-going monitoring and assessment need to take place.

5. Concluding Remarks

The API-for-Justice project experience provides the opportunity to gaze at the challenges posed by the attempt to make the European justice service provision smarter through the involvement of external service providers. The relatively simple idea of developing APIs to open up the existing e-Justice infrastructure and allowing third parties to develop APPs and provide services to end-users is linked to multilayered sociotechnical and legal complexity, which needs to be addressed, which the theoretical framework building on Meijer and Rodríguez Bolívar [24] and Velicogna [11] allows us to explore from a comprehensive perspective. This case study shows how the European e-Justice Digital Service Infrastructure governance mechanisms, developed to manage the traditional service provision and the ‘closed’ infrastructure, are not adequate for the new purposes. Moreover, the API-for-Justice project team began exploring the reconfiguration potential of the opening up of the infrastructure to third party smart service providers and noted that unpredictable drifts can emerge from opening up the infrastructure. In the old e-Justice paradigm, the end user interacts with the system through the interface provided by the institutional actors (e.g., e-Justice Portal, Ministries of Justice, etc.), who typically allow access to the infrastructure on the basis of a use-case-centric approach. In the new paradigm, not only will the institutional actors’ service provision be simplified by the introduction of APIs, but the end users will be able to interact with the system through APPs developed by third parties with a more user-centric approach, which will access the infrastructure through the APIs of the Commission or of one of the Member States. While, on the one hand, this can provide a source of innovation and smarter service provision, on the other hand it opens justice services up to the risk of compromising institutional values and destabilizing consolidated practices.

As Brenner noted, the transformation that will take place between the end user and the smart service will reduce the necessity of a conscious interaction with the public authority for carrying out the court procedures. This has the potential to reshape the roles of the participants in the interaction and may have serious consequences for the capability of the existing legal framework to regulate them. As it emerged in the analysis carried out in the API-for Justice project, the existing framework is based on our understanding of traditional technologies and service provision. Moving in the uncharted waters of smart technologies and smart service provision mediated by third party service providers will require an experimental stance, capable of grasping and adapting to the emerging novelty. While this analysis focuses on the justice domain, the author considers that these features and dynamics characterize the quest for smartness at a more general level.