9 Key Decision Log
Decision
By
Date
Description
Security related requirements to remain in this document
Hani and Max
4th August 2021
It was suggested that since security is more cross cutting concerns and some components that the cross cutting concerns should be relocated to the architecture WG document. It was decided that all security related requirements are to remain in this document and shall be cross referenced from the other BB definition documents.
Example API specification references added for each component
Security WG
4th August 2021
It was decided that an example API definition for each functional component of the security solution where applicable was to be added to this document for clarity. The basic assumption here is that the base of security components required to address all cross cutting concerns will be off-the-shelf open source solutions. We do not anticipate building a substantial suite of API’s when the components should all be standards based and integrated. It would be far more costly for the project to engineer security components from the ground up.
A resource model for the IAM aspects of the security requirements is to be added for clarity
Security WG
4th August 2021
It was decided to add a resource model for the purposes of determining the suitability of various IAM suites for the project. The resource model can be used as a basis to determine which entities the solution supports.
The decision to include SAML in the requirements was taken
Security WG
4th August 2021
The purpose of including SAML is that federation of legacy environments is likely required and we cannot predict this in advance as we have no specific country context and must address a generic set of requirements that can be adapted to all settings.
Added sequence diagrams for describing account creation, processing service access requests and the basics of API gateway operations.
Security WG
11th August 2021
Met with the registration BB and we discovered that their design model required accounts to be created with a minimum of email and/or mobile number. This meant that the provisioning of access to services needed to be a separate process. So these two processes were detailed in sequence diagrams
Added basic API examples for the purpose of clarifying the intent of how the IAM solution will deliver authentication and authorization services.
Security WG
11th August 2021
There have been many questions from various WGs about how the basics of authentication and authorization will function. Some description of this has been added to the document along with examples of how OpenIAM implements both REST and OAuth2 authentication and authorization.
Added a high level resource model
Security WG
11th August 2021
A high level resource model based on a domain driven design has been added to help clarify the overall context of the Security BB.
Reviewed and modified sequence diagrams
Security and Architecture WG
19th August 2021
Using an in-depth discussion with the Registration BB we modified all of the sequences for account creation and provisioning for consistent use across all BBs.
Renumbered requirements items for ease of reference
Security WG
20th August 2021
All of the detailed requirements have now been indexed with numbered headings and are available as links through both the ToC and to other documents. This was done for ease of reference by the other BBs.
\
Accepted and cross link inserted in the introduction section of this document
BB module (see Ref 1) in the above sentence on page 116, and occurring twice on page 151 may be hyperlinked, within the document, to the URL at Ref#1, under section 6: Cross reference links, on page 154
Hyperlinks added for all referenced standards.
For (see Ref 2) and (see Ref 3) may be suffixed to “NIST CyberSecurity Framework” on pages 19-20, and “NIST 800-171 Rev.2 standard” on pages 20. Both the suffixes may be hyperlinked, within the document, to the respective URLs at Ref#2 and Ref#3 respectively, under section 6: Cross reference links, on page 154.
Hyperlinks added for all referenced standards.
The Section 4: Security Building block modules:
(Suggestions: (see Ref 1) in the last sentence of the opening paragraph, on page 116, “Explicitly, (see Ref 1) the communications between all building blocks (BB’s) and applications shall be via open API based access.”, may be corrected.
(see Ref 1) in the above sentence on page 116, and occurring twice on page 151 may be hyperlinked, within the document, to the URL at Ref#1, under section 6: Cross reference links, on page 154.
5.11 Denial of Service Attack Prevention Requirements
1. Under 5.11.3 Volume Based Attack Prevention:, the word “Which” in the phrase “1) Attack Prevention and Preemption: Which is done” of the second last line, on page 57, may be replaced by the word “This”, to maintain uniformity with the description of the following two ways.
2. Under 5.11.4 White Lists:, on page 58, the ‘usr’ in the phrase “normal usr operations” may be reviewed.
Thanks for suggestions, corrections adopted
Out of Scope Suggestions
These 59 security requirements could be mapped to the 20+ BBs as listed in the DIAL document, to show which requirement applies to what BB. In countries with low or limited resources (our target), are all these requirements essential? Aren't these overkill? We are working towards minimum viable architecture (MVA).
This document compiles recommendations to be referenced by each building block specification to make these principles part of the reference implementations, as early as possible. The list is comprehensive, but picking specific recommendations of this list that match MVA constraints of a target country will be an implementation time team decision and not in scope of this document
The purpose of yellow coloured text highlighter used for “4.4 Workflows”, on page 144, and for “4.4.4 Example Sequence Diagrams for API Gateway Services:”, on page 151, may either be explained, or the highlighted text may be formatted to “No color”.
The yellow text is how Google Docs indicates that a reviewer has placed a comment at that point. The released documents will be PDF files and will not display the comments.
Overall across the Architecture and the e.g. ID and other BBs, the ownership of ID management is unclear. There seems to be an aspiration for each BB to be self-sufficient yet for example if a government were to adopt all BBs would there be multiple ID management components? There is mention of a "registration server" in the ID BB & a "Security server" in Architecture BB. It probably deserves a conversation e.g. is there going to be a centralisable Directory serving each BB?
The foundational root of trust for legal person ID is with ID BB. Functional IDs Without exposing this ID, token IDs can be generated by the ID building block for use in different building blocks. For example, a token id for payment purposes only, may reside inside Payments BB of the finance ministry for a mapper that links the ID to specific payments accounts of a person. A different token Id may be issued for the health sector, for linking a person to a health record repository in a health ministry application. One can further opt to issue token IDs derived from the root, to associate with only a particular program (e.g mother and child care program) within a sector (e.g healthcare) or even a particular entity (e.g. a bank) authorized within a program.
The security server is the implementation of IM BB. There is a security server in front of every BB (bridge to internet).
The process of registration is handled by the Registration BB. Different part of information collected during registration may be parked and protected inside specific BBs that own the jurisdiction of respective data
The purpose of yellow coloured text highlighter used for “AI/Deep Learning (Collaborative)” under “5.23.2 General Features Required:” on page 85, and the text below “5.27.3 Example REST Authentication API”, on page 97, may either be explained, or the highlighted text may be formatted to “No color”.
The yellow text is how Google Docs indicates that a reviewer has placed a comment at that point. The released documents will be PDF files and will not display the comments.
The Section 2: Introduction
(Suggestions: (see Ref 2) and (see Ref 3) may be suffixed to “NIST CyberSecurity Framework” on pages 19-20, and “NIST 800-171 Rev.2 standard” on pages 20. Both the suffixes may be hyperlinked, within the document, to the respective URLs at Ref#2 and Ref#3 respectively, under section 6: Cross reference links, on page 154. Necessary action may be taken for the TBD entries in the table against S. Nos. 6, 7, 13, 14, 15, 16, 17, 18, 20, 22, 25, 33, 34 under the column “Description, Discussion and Potential Solutions”.
- (see Ref 3) may be suffixed to “NIST 800-171 Rev.2”, mentioned against S. No. 58, under the column “Description, Discussion and Potential Solutions”, on pages 36. The suffix may be hyperlinked, within the document, to the URL at Ref#3, under section 6: Cross reference links, on page 154.
The Section 5: Cross-functional requirements
5.1 Privacy
(see Ref 3), on page 38, may be hyperlinked, within the document, to the URL at Ref#3, under section 6: Cross reference links, on page 154.)
5.6 Certificate Authority Functional Requirements
(see Ref 1) at the end of 5.6.9 Standards Based API Interface, on page 44, may be hyperlinked, within the document, to the URL at Ref#1, under section 6: Cross reference links, on page 154.
The Section 5: Standards:
(see Ref 2), (see Ref 5) and (see Ref 3), on page 154, may be hyperlinked, within the document, to the respective URLs at Ref#2, Ref#5 and Ref#3 respectively, under section 6: Cross reference links, on page 154.
These changes may become redundant as the document will be realigned with appropriate sections to reduce the number of repeats and hyperlinks.
\
Last updated