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 | |
Cross-cutting Requirements :
5.1 Follow TM Forum Specification REST API Design Guidelines Part 1 (REQUIRED) | ||
TMF630 REST API Design Guidelines 4.2.0 | Could be implemented | |
APIs MUST not include Personally Identifiable Information (PII) or session keys in URLs - use POST or other methods for this | Implemented | Same approach |
MUST support caching/retries | Implemented | |
Implemented | Same approach | |
Implemented | Same approach | |
Implemented | Same approach | |
5.2 Follow TM Forum Specification REST API Design Guidelines Parts 2-7 (RECOMMENDED) | Could be implemented | |
5.3 Communicate with other BBs only via API (REQUIRED) | ||
All BBs must expose their data and functionality through service interfaces (APIs). | Implemented | If a BB needs to expose some integration point with him, it is often revealed as Rest API. If the component is not designed to expose some communication points to other clients, then not Rest API. |
Building Blocks communicate with each other through these interfaces. | Implemented | Same approach |
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. | Implemented | Same approach |
It doesn’t matter what technology is used. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. | Implemented | Yep, it does not matter what technology is used |
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. | Not the same approach | Some components are designed not to have Rest API exposed, and a component responsibility by design defines this. Some components could be just a client for some other components. |
Building blocks MUST NOT use shared databases, file systems or memory for data exchange with other building blocks. | Implemented | We are not talking here about NFS, etc. |
5.4 APIs must be Versioned (REQUIRED) | ||
Use semantic versioning when documenting changes to API definitions. Any breaking changes to APIs MUST use a different endpoint, as shown here: e.g. /api/v1 and /api/v2 | Implemented | Same approach |
5.5 Documentation must be Provided (REQUIRED) | ||
Documentation on the installation and use of the Building Block MUST be provided. Where possible, this documentation SHOULD be stored alongside code in a repository. Documentation MAY be generated from code where applicable. | Not the same approach | Documentation is provided for the entire set of BB included in the installer (defined by a specific version number). |
5.6 Provide an OpenAPI specification (REQUIRED) | ||
Each building block’s service APIs MUST be defined and exposed using a standardized machine-readable language. | Implemented | OpenAPI specification |
5.7 Building blocks must be deployable as a container (REQUIRED) | ||
Each building block MUST be ready to be deployed as independent container images. Source code and build instructions SHOULD be committed to a public code repository where possible. | Implemented | Same approach |
A building block may be composed with Kubernetes or docker compose. All build files must be included alongside the source code. | Implemented | Same approach |
5.8 Include all deployment scripts (RECOMMENDED) | ||
When a building block requires deployment tools such as Kubernetes or Ansible, configuration and deployment scripts should be included in the building block repository. Use of this type of deployment configuration will make individual components of the building block independently scalable and make building blocks less monolithic and more efficient. | Implemented | Helm chart configurations living together with components source code |
5.9 Comply with GDPR Principles (RECOMMENDED) | ||
Building Blocks SHOULD conform to GDPR principles, including the right to be forgotten account deletion, and privacy requirements to protect the rights of individuals. Note that these requirements may vary by region, and building blocks must conform to regulatory requirements wherever they are deployed. | Could be implemented | |
5.10 Include Support for Capturing Logging information (REQUIRED) | ||
Building Blocks MUST have a mechanism for generating logging information. This may be as simple as using STDOUT and capturing through docker logs, or may use other log sinking technologies. | Implemented | Same approach |
5.11 Use Web Hooks for Callbacks (REQUIRED) | ||
When Building Blocks require callback functionality, they must use webhooks and not direct links to functions within the building block. | Could be implemented | |
5.12 Enforce Transport Security (REQUIRED) | ||
All Building Blocks MUST support secure HTTPS transport with TLS 1.3 and insecure cyphers disabled. | Could be implemented | Not all BBs use TLS for communication inside OKD. However, all external/public communication is secured and encrypted. |
5.13 GET and PUT APIs must be Idempotent (REQUIRED) | ||
Implemented | Same approach | |
5.14 Use Stateless APIs wherever Possible to Enhance Scalability (RECOMMENDED) | ||
API calls SHOULD be able to be made independently of one another. Each API call should contains all of the data necessary to complete itself successfully. | Implemented | Same approach |
5.15 Include Transaction/Trace/Correlation IDs (RECOMMENDED) | ||
Transactions that cross multiple services SHOULD provide a correlation ID that is passed with every request and response. This allows for easier tracing and tracking of a specific transaction. | Implemented | Same approach |
5.16 Include Clearly-Defined Key Rotation Policies (RECOMMENDED) | ||
Some blocks may require the use of security keys. Those that do must have clearly defined key rotation policies to enhance security | Implemented | Same approach |
5.17 Databases should not Include Business Logic (RECOMMENDED) | ||
Database processing tools like triggers and stored procedures should be avoided. | Implemented | Triggers were used only for tech purposes and had no business logic implemented. |
5.18 Use only Unicode for Text (REQUIRED) | Implemented | |
5.19 Use ISO8601/UTC for Timestamps (REQUIRED) | Implemented | |
5.20 Building Blocks must be Autonomous (REQUIRED) | ||
Each building block MUST be capable of running independently, without requiring other dependencies such as external data stores or other building blocks. | Not the same approach | Registry-level components are often dependent on platform-level components |
5.21 Use Secure Configuration (REQUIRED) | ||
Configuration MUST be done using secure processes, such as environment variables or a secure secret store. | Implemented | Hashicorp Vault |
5.22 Design for Asynchronous First (RECOMMENDED) | ||
Designs should support occasional connectivity/low bandwidth, and should allow for asynchronous communication between building blocks. A Publish/Subscribe design pattern can be used to handle changes, allowing loosely-coupled solutions to be assembled without changing existing APIs. | Not the same approach | We are using a pub/sub communication model, but this is not required for all communication channels to be implemented, so not all communications could be async. Some of the communications channels could be only synced by design. |
5.23 Use Standardized Data Formats for Interchange (REQUIRED) | ||
Implemented | Same approach | |
5.24 Use Existing Standards for Data Interchange, Where Available (RECOMMENDED) | ||
If an existing standard is available, it should be used, e.g. DICOM/Hl7/FHIR for healthcare. TMForum has a large library of standardized APIs and data models that can be used. | Implemented | If the existing standard is applicable, it will be used. But this point does not mean we need to have adaptors implemented for all of the current standards and protocols beforehand. |
5.25 Use I/O Sanitization (RECOMMENDED) | ||
Building blocks SHOULD validate all incoming data to ensure that it conforms with the expected format and type. APIs should also sanitize incoming data, removing any unsafe characters or tokens. | Could be implemented | |
5.26 Provide a Compliance Test Mock/Example Implementation (OPTIONAL) | ||
https://github.com/GovStackWorkingGroup/bb-template/tree/main/examples | Could be implemented | Some of the components mocked on an API level to be tested appropriately |
5.27 Building blocks should be Localizable (RECOMMENDED) | ||
Where a building block has a human user interaction, it SHOULD be able to present information to the user in their local language. Building blocks should be designed to support multiple locales. | Could be implemented | Planned to be implemented |
5.28 Use NTP Synchronization (RECOMMENDED) | ||
Where precise timestamps are required, building blocks SHOULD leverage Network Time Protocol (NTP) to synchronize timestamps between servers. | Implemented | |
EOL SHOULD be at Least 5 Years | ||
No languages, frameworks, or dependencies should be used in a building block where that component has an EOL of less than 5 years. | Implemented | Implemented |
Preference for TIOBE Top 25 Languages | ||
Where possible, building blocks SHOULD be written using commonly used languages to ensure ongoing maintenance and support are as easy as possible. Building blocks MAY leverage less common languages, such as shell scripting where needed. | Implemented | |
Regular Security and Code Quality Audits SHOULD be Run | ||
Implemented | Same approach | |
SHOULD Include Unit and Integration Test Coverage | ||
Building blocks should include tests that provide both unit and integration test coverage | Implemented | Same approach |
SHOULD Follow Best Practices for Public Code | ||
Code in the Open | Implemented | |
Bundle Policy and Source Code | Implemented | |
Create Reusable and Portable Code | Implemented | |
Welcome Contributions | Implemented | |
Maintain Version Control | Implemented | |
Require Review of Contributions | Implemented | |
Document Your Objectives | Implemented | |
Document your code | Implemented | |
Use plain English | Implemented | |
Use open standards | Implemented | |
Use continuous integration | Implemented | |
Publish with an open license | Implemented | |
Use a coherent style | Implemented | |
Pay attention to codebase maturity | Implemented | |
Onboarding Products :
6.1 Adapters | ||
Adapters connect GovStack building blocks to existing applications. There are many possible flavors of adapter, e.g. HL7 2.5, HL7 3.0, FHIR, SAP SOAP, SQL and many others. Each flavor can be quickly configured to give GovStack access to existing resources. | Could be implemented | SOAP, and RestAPI adaptors have already implemented |
6.2 API Gateways | ||
API gateways connect citizens and existing applications to GovStack Building Blocks. The API gateways map outbound API calls from the application into API calls that will be used and understood by the GovStack Building Blocks. | Implemented | |
Any number of API gateways can be added to expose various GovStack services to users or external applications, each of which have different security requirements on the information mediator and public internet/API Gateway sides. | Implemented | It is true if we are talking about development phase |
6.3 Native GovStack Implementation | ||
The highest level of integration involves existing products implementing APIs that can be directly consumed by other GovStack Building Blocks. | Implemented | We are fully committed to supporting the requirement for the highest level of integration in the Registry Platform. We are ensuring that all existing components have well-defined APIs that can be directly consumed by other Registry Platform components. |
Standards :
7.1 Unicode | ||
Implemented | ||
7.2 ISO8601/UTC | ||
https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC) | Implemented | |
7.3 JSON | ||
Used for exchanging data | Implemented | |
7.4 JSON Schema | ||
Implemented | ||
7.5 REST | ||
Used for implementing APIs | Implemented | |
7.6 OpenAPI 3.1 (AKA Swagger) | ||
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md | Implemented | |
7.7 Docker/Docker Compose/OCI Containers | ||
Implemented | ||
7.8 QR code | ||
Must be generated with the ISO/IEC 18004:2015 standard | Could be implemented | QR codes integration planned to be implemented |