Summary :
Both architecture approaches are designed to work in the cloud environment. |
Both architecture approaches rely on open-source components and frameworks. |
The digital registry platform operates with instances that are similar to the GovStack Digital platform, which provides services to citizens. |
There is no global Service Registry component introduced in the registry platform. Each platform instance is only aware of the registries deployed in it. There is no global discover/registry component that is aware of all registry instances in a country. |
The registry platform is not responsible for the information mediator, but its components can communicate through it. |
It is not possible to deploy each component separately without communicating with other required building blocks. Therefore, each registry instance is independent of another registry instance, but all registry instances are dependent on core common platform components (components required for operating the platform instance). |
For now, there is no self-owned certificate authority management. |
Introduction :
SDG Digital Investment Framework | ||
Reusable software components | Implemented | Same approach |
Licensed as open source, proprietary, or freely available with Open Access to data | Implemented | Same approach |
Facilitates one or more generic Workflows | Implemented | Same approach |
Applicable to multiple SDG Use Cases across multiple sectors | Implemented | Same approach |
Interoperable with other ICT Building Blocks | Implemented | Same approach |
Designed for Scalability | Implemented | Same approach |
Designed for Extensibility | Implemented | Same approach |
Standards Based Conformance or Compliance | Implemented | Same approach |
Digital Public Goods Alliance (DPGA) | ||
Refers to software code, platforms, and applications that are interoperable, provide a basic digital service at scale, and can be reused for multiple use cases and contexts. | Implemented | We are providing digital service (digital registry platform) at scale, and it can be reused for multiple use cases by developing separate registry-regulation configurations for each use case. |
Serves as a component of a larger system or stack. | Implemented | Same approach |
Can be used to facilitate the delivery of digital public services via functions, which may include registration, scheduling, ID authentication, payment, data administration, and messaging. | Could be implemented | Payments not implemented yet |
Building blocks can be combined and adapted to be included as part of a stack of technologies to form a country’s DPI. | Implemented | Set of components included in an installation package |
Building blocks may be open source or proprietary and therefore are not always DPGs. | Implemented | Only opensource based components |
“Building blocks can be as simple as a common set of rules or protocols (for example email programs like Simple Mail Transfer Protocol - SMTP), or complex (for example an open-source health information system like the DPG, District Health Information Software - DHIS2)“ | Implemented | The Registry platform components could be simple and complex. But in real life, all of them are simple. |
Autonomous: building blocks provide a standalone, reusable service or set of services, they may be composed of many modules/microservices. | Implemented | The responsibility of a single BB could be represented by a set of components in the registry platform. |
Generic: building blocks are flexible across use cases and sectors. | Implemented | Same approach |
Interoperable: building blocks must be able to combine, connect, and interact with other building blocks. | Implemented | Components could communicate with each other using RestAPI within a single platform instance. |
Iterative evolvability: building blocks can be improved even while being used as part of solutions. | Implemented | Components could continue developing while already in prod. |
Open API, Open API Specifications, Rest API | Implemented | Same approach |
Packaged in a container | Implemented | Same approach |
Include a information mediator where communication flows between services that are not co-located | Not the same approach | Information mediator BB is not a part of the registry platform distribution and responsibility in general. |
2.3 Building Blocks | ||
A Central Operator is responsible for maintaining a registry of members, the security policies for building blocks and other member instances, a list of trusted certification authorities and a list of trusted time-stamping authorities. The member registry and security policies MUST be exposed to security servers over HTTP. | Implemented | An owner of the registry platform instance managing the keylock instance. |
Building blocks are software modules that can be deployed and combined in a standardized manner. Each building block is capable of working independently, but they can be combined to do much more: | Not the same approach | Components utilising standard platform components and dependent on them. Registry level platform requires platform components to be deployed beforehand to operate with. Also, there could be some dependencies between registry-level components (let's say some features could depend on the DataFactory component). |
Certificate authorities are responsible for issuing and revoking certificates used for securing and ensuring the integrity of federated information systems. Certificate authorities MUST support the Online Certificate Status Protocol (OCSP) so security servers can check certificate validity. | Not the same approach | We do not have explicit self-CA up and running. We are using LetsEncrypt and internal CA capabilities by OKD (OKD and Istio internal mechanism) |
Building blocks are composable, interoperable software modules that can be used across a variety of use cases. They are standards-based, open source and designed for scale. | Implemented | Same approach |
Each Building Block represents, as much as possible, the minimum required functionality (MVP) to do its job. This ensures each Building Block is usable and useful on its own, and easily extensible to support a variety of use cases. | Implemented | Same approach |
A Building Block is composed of domain-driven microservices, modeled as closely as possible on existing roles and processes. This helps ensure each building block is as useful as possible in the real world. | Implemented | The responsibility of a single BB could be represented by a set of components in the registry platform. |
Building Blocks exchange data using lightweight, human-readable data that can easily be extended where needed. Data models and APIs are described in a lightweight manner that’s human-readable, allowing them to be easily and quickly understood and validated. | Implemented | RestAPI OpenAPI description and additional model description in documentation |
2.3.1 Building Blocks and UI/UX | ||
An admin-only form builder which facilitates building user interfaces (e.g., select questions to be displayed in a maternal-and-child-health registration process) | Implemented | Form.io web-based form modeller within admin-tools component |
User interfaces (i.e., forms) which can be used in lieu of individual end-user apps building their own forms (e.g. I’m building a new maternal and child health application; I’d like to use a registration screenflow that’s been pre-built in the registration building block as part of a larger, composed application.) | Implemented | Each form from a registry-regulation repository can be used in any BP definition within the same registry instance. |
A public API which exposes the critical back-end services performed by this BB (adding a mom to a database; checking for a mom’s enrollment status in a program) to be used (as a microservice) by existing or new applications with legacy/bespoke needs (e.g., i’ve already got a maternal and child health app that the CHWs are using, and I want to send a webhook to the registration BB after a CHW clicks “submit” on our custom form.) | Implemented | Public Rest API could be treated as separate component as well |
2.4 Cross-Building Block Communication | ||
A building block is only so useful on its own. In practice, building blocks MUST be connected together in a secure, robust, trusted manner that facilitates distributed deployments and communications with existing services. | Implemented | Components could communicate within the same registry instance using RestAPI interfaces or do a cross-registry instance communication using a mediator component or any other secured connectivity in place |
It is STRONGLY RECOMMENDED that a building block use an information mediator (as described below and in the Information Mediator Building Block specification) for any communications across the internet. An Information Mediator is not required for communication between building blocks which are co-located. | Implemented | It is not the responsibility of the component to choose a connectivity way. It is more on infrastructure developers to choose the right way to organise connectivity between members which is not part of a single registry instance. |
2.4.1 Federation and Data Exchange Requirements | ||
Each building block deployment SHOULD use an Information Mediator to federate and communicate with other data consumers and providers, particularly when communicating between services that are not co-located. This ensures the confidentiality, integrity, and interoperability between data exchange parties. | Implemented | It is not the responsibility of the component to choose a connectivity way. It is more on infrastructure developers to choose the right way to organise connectivity between members which is not part of a single registry instance. |
2.4.2 Organizational Model | ||
First, a central operator will be identified and created. This organization will be responsible for the overall operation of the system, including operations and onboarding new members. Policies and contractual agreements for onboarding need to be created. | Implemented | The central operator is an owner organisation of the registry instance |
Trust services need to be set up internally or procured from third parties, including timestamp and certificate authorities. This provides the necessary infrastructure to support distributed deployments. | Could be implemented | No self-owned trust services are built into a platform for a moment. Only OKD and Istio internal mechanisms are in place, which use self-signed certificates and validation processes. |
Finally, members can be onboarded and provided with access to the Information Mediator and methods to register the services that they provide as well as discover services that are available. | Implemented | This can be done, but the information mediator is not a responsibility of the registry platform as well |
Once agreements are in place, members can deploy new services in a decentralized, distributed manner. Before deploying a new service, the central operator must be notified of any changes to access-rights, including organization and machine-level authentication before it can publish or consume data. | Implemented | Once agreement is in place, new registries could be deployed in a new or existing Registry Platform instance |
2.4.3 Technical Architecture | ||
A Central Operator is responsible for maintaining a registry of members, the security policies for building blocks and other member instances, a list of trusted certification authorities and a list of trusted time-stamping authorities. The member registry and security policies MUST be exposed to the Information Mediator over HTTP. | Implemented | Same approach |
Certificate authorities are responsible for issuing and revoking certificates used for securing and ensuring the integrity of federated information systems. Certificate authorities MUST support the Online Certificate Status Protocol (OCSP) so that an Information Mediator can check certificate validity. | Could be implemented | No own CA support for a moment. It could be implemented. |
Time-stamping authorities securely facilitate time stamping of messages. Time stamping authorities MUST support batched time stamping. | Could be implemented | No Timestamping authorities for a moment |
The Service Registry provides a mechanism for building blocks to register the services that they provide and for other building blocks to discover and consume those services. Any services provided or consumed by a Building Block that leverages the Information Mediator architecture MUST use this service registry functionality. | Not the same approach | Registry Platform do not have any central registry service in place |
2.5.1 Building Block-specific definitions | ||
Registration: Any approval/license/certificate issued by a public entity as a result of a request/declaration made by a user of the public service. The result of a “registration” is usually a number and/or a document (called certificate, license, permit, authorization, registration, clearance, approval, etc.) | Implemented | We could have different naming for the same thing, but as a business process execution result, we could have some documents created. |
Authentication: This is the technical process of establishing that the credentials (i.e. username, password, biometric etc.) provided by a party (user, system, other) is valid and that the party can be granted basic access to system resources with default access rights. Note that authorization also needs to be applied for a party to access protected resources. | Implemented | Same approach |
Authorization: This is the technical process of establishing whether or not an authenticated party has rights to access a given protected resource. Access rights can typically be granted or revoked administratively on a read-only and/or read-write and/or execute basis through an administrative provisioning process. Permissions or rights defined for a party typically manifest in an access token that is granted at the time of authentication for the party. Hence the processes of authentication and authorization are intrinsically related. | Implemented | Same approach |
(Workflow) Activity - a single step in a workflow process. | Implemented | Same approach |
(Workflow) Process - a workflow process contains one or many activities. | Implemented | Same approach |
(Workflow) Instance - an instance of execution for a workflow process. | Implemented | Same approach |
Building Block Design Principle :
4.1 Citizen-Centric | ||
Right to be forgotten: everything must be deletable | Implemented | Historical data could be present in a historical table, but not visible in a main table |
User-centered design | Implemented | Same approach |
4.2 Open | ||
Based on open standards | Implemented | Same approach |
Implemented | ||
Built on open-source software (where possible) | Implemented | Same approach |
Supports open development, see https://standard.publiccode.net/ | Implemented | |
No vendor lock-in | Implemented | |
Cloud native (Docker/Docker Compose/OCI containers) | Implemented | Cloud ready |
Code is openly developed and available to anyone, via Github or Gitlab | Implemented | Same approach |
4.3 Sustainable | ||
Implemented | ||
Continuous funding for maintenance, development and evolution | Implemented | |
Attractive to ICT industry and individual developers in deployment environment (incentives must be aligned) | Implemented | |
Lower cost than commercial solutions due to shared development costs | Implemented | Potentially, we need to estimate a cost of at least. |
Uses microservices-based architecture instead of monolithic. | Implemented | Same approach |
4.4 Secure | ||
Blocks are audited and certified before being made available | Implemented | Security pipelines processing artefacts and containers are signed. |
Development processes and standards enforce quality and security | Implemented | Same approach |
Different certification levels reflect level of standards-compliance | Implemented | |
Regular security scanning and auditing | Implemented | We have a bunch of automatic tools for scanning in aCICD pipelines as well as a manual security auditing process (which happens periodically) |
Public ratings and reviews | Could be implemented | |
Comprehensive logging and exception handling | Implemented | |
4.5 Accessible | ||
Meets users where they are: web, mobile, SMS and/or voice. UI supports accessibility technologies, e.g. screen readers. | Could be implemented | No accessibility functionality for a moment, no voice communication between end-users for a moment |
SSO allows for signing in once for multiple services | Implemented | Same approach |
Shared ownership of code | Implemented | |
Deployment and development processes and standards are open to contributors | Could be implemented | |
Community-driven development tools for documentation and support | Implemented | ascii doc documentation published using Antora |
Blueprints, templates and documentation | Implemented | Same approach |
4.6 Flexible | ||
Blocks can be reused in multiple contexts | Implemented | Any component potentially could be reused in any context in which it is fit basically |
Each block is autonomous | Not the same approach | Registry-level components are often dependent on platform-level components |
Blocks are interoperable | Implemented | Same approach |
Easy to set up | Implemented | Platform installer is not complex the thing to operate with |
Standardized configuration and communications protocols connecting blocks | Implemented | Same approach |
Blocks can be provided as a service (ICT opportunity) | Implemented | Each deployed component could be treated as a service in a digital platform |
4.7 Robust | ||
Any client-facing functionality should operate in low-resource environments: Occasional power, Low bandwidth, Low-reliability connectivity | Not applicable | We are not responsible for any hardware on which the platform instance is deployed. This is the responsibility of the platform instance owner. |
Easily scalable for high availability and reliability | Implemented | |
API-only based decoupling | Implemented | |
Asynchronous communications pattern decoupled through rooms is ideal | Implemented | |
Eventual consistency for data | Implemented | |