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
]. 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
]. 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
]. 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
]. 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
]. 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
]. 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
]). 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
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?
Legal: What is the legal framework for an API?
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
]. 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.
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
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.
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.
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.