GovStack’s Specifications must not aim for compliance to one specific regulation. Otherwise, they would risk global validity and the freedom of local regulatory sovereignty.

For an organization to comply to a regulation, there are typically procedural, organisational and legal settings required in addition to the technical capabilities of an IT system (for example, what makes the certification of a civil registry valid is not the electronic signature it was used to sign it, but the process, authority, legality and institutional scaffolding that support the validity of the act of signing). Working Groups building GovStack Specifications must be careful to separate what belongs to the domain of institutional governance from the functionalities and standards that enable an organization to provide a service.

Inputs of specification work

The working groups consider several inputs (business requirements) to derive the technical functional requirements of a software (Building Block):

1. Common use cases/e-services in eGovernment

2. Common organisational structures in governments

3. Common regulations and policies

4. Universal Declaration of Human Rights and UN Universal Safeguards for Inclusive Digital Public Infrastructure

The more and diverse the input from these four categories, the better and universal the output. Most important, it is to be noted, that it is a one-way dependency. While an input has influenced the working group to include a technical requirement, fulfilling a technical requirement does not by default mean the fulfillment of a regulatory requirement. Technology supports, rather than precludes, legality.

Sovereignty over choice of software and regulation

Our approach sets only the minimal mandatory technical requirements for the function. It then allows maximum adaptability for different regulatory approaches. This ethos is guided by our view that digital sovereignty is a right for countries that choose the GovStack approach. Similarly embedded in our approach is the necessity to have multiple compliant software solutions to a building block rather than specify a single solution, to allow an implementor choice. Is also our approach on regulatory sovereignty. If we were to dictate a specific regional regulation rather than understand national regulatory input alongside global technical expertise, we would drive a dominance that is opposed the digital sovereignty that GovStack has in its ethos.

Example of Wallet Building Block

The GovStack Wallet Building Block specifications would allow a country to apply national regulations or even make a conscious decision to follow regulation of another regional context. For example, it might decide to follow EU regulation – especially if it aims to join the EU. For that purposes, GovStack tested to draft so called “Building Block Implementation Guides” which support countries in using technical specifications and on top align with selected regulations.

While following GovStack specifications might allow technical cross-border interoperability, the choice of regulatory framework has significant impact on the trust between countries and therefore recognition of services across borders. Taking Wallet Building Block again as an example, while all countries might issue the same credential, some might not be accepted because issuance and verification practices are weak. Technical compatibility is not enough; trusted processes, clear liability, and robust oversight are essential for mutual recognition.

Our plans to bridge the gap

The strict separation of technical and regulatory requirements comes with a gap that implementers need to bridge. By using GovStack technical specifications alone, an implementer wouldn’t know, if a regulation’s requirements are met or not. This unknown gap is different under various regulations.

To support implementers bridging the gap, GovStack will develop ‘Implementation Guides’. These guides will explain how to deploy a Building Block in practice, cover default configurations, reference integrations, and compliance checkpoints. A Building Block technical specification might be accompanied by several guides: one generic pattern, plus region-specific versions that address legislation such as eIDAS for identity or PSD2 for payments

GovStack’s support in achieving institutional capabilities, governance and regulatory compliance

An organisation undertaking a Digital Transformation strategy will face much more than introducing new IT systems. Often governments around the world deal with their unique package of available regulations they must comply, institutional capabilities and budget, and infrastructure that may or may not be up to par. Through implementing our offerings in countries throughout the globe, the GovStack community has built several instruments we continue to improve to help implementers address the many parts of this journey:

• Our Public Administration Ecosystem Reference Architecture (PAERA) document provides guidance strategic teams undertaking a wider digital transformation journey. It is aimed at describing the institutional governance, responsibility and decision-making scaffolding necessary for implementing such strategy. It centers itself in bridging the gap between policy makers and IT builders by providing them with a useful framework of concepts, roles, tooling and responsibility for the joint work they will face.

• The Implementation Playbook serves as a manual for smaller teams tasked with the digitalisation of services. It is packed with practical tools and exercises to track which services to digitalise, what legal instruments are available or missing and identifying the existing and potential institutional capacity to undertake it.

• Local and Regional Implementation Guides, see chapter above. Newly introduced after the publication of the GovSpecs 2.0 strategy. Generic Implementation Guides will explain how to deploy a block in practice, cover default configurations, reference integrations, and compliance checkpoints. Region-specific versions will address implementation considerations under specific legislation.

Authors: Ali González, David Higgins, Nico Lueck