10 Future Considerations

Suggestion	Response
Is there a reason for only "exposed"? API's should be externalizable and should not rely upon security outside their control.	Presently we are not considering securing APIs that are internal to a building block within scope. However, based on specific implementation requirements and internal components required, this may be specified in future scope.
From a conversation with Kristo: some of these requirements apply to the deployment/project, and some map more directly to building blocks and engineering requirements. Perhaps we should separate these into two groups	Consider separating into sections. This will help focus the building blocks on just the requirements that apply to the product at this point. We can address the others when it comes to deploy and in like the networking BB spec.
Security document contains sections that can be moved to architecture document e.g API design principles, NFRs like availability, scalability, etc.	This will be normalized with the Architecture document in future release
Operational best practices like VAPT, infra security should be separated with the design/development time general security principles.	Different requirements have been tagged as design/build/deploy requirements. This will be called out in separate sections in next release.
Document is too exhaustive and it would be better to keep key summary check list for all the BB to easily follow.	Security check list should match the selected feature list based on infra constraints. An example check list can be prepared in future release for reference to develop such checklists suitable to a target implementation
Some of the sections are repeating themselves. It will be better to reorganize these to core sections. Fine, better to understand	In the next release re organize the sections to minimize repetition and introduce cross links as needed.
At the beginning, a one-page pictorial and summarised representation of how GovStack approach	A generalized introduction will be provided in Govstack website and all building blocks will carry links from there. Links to general introduction page can also be inserted the for cross reference from this document
Separate documents for Security building block specifications and security guidelines to keep focus on general security guidelines and security building block features for different audiences.	The security recommendations and Security BB specs are currently separated into different sections. In next release these will be separated into different documents, for specific end use - for adopting security principles in build building block development and for implementing security building block in a network.
At the end, a section on as many use cases of this BB-based implementation solution, another on success stories using this BB, and lastly a tutorial with exercises for capacity building of existing and prospective Government executives. It can be used as a module of the “Digital Transformation in Government” course/ module for management/ B-schools and administrative training colleges/ institutes of the Government.	Links to case studies, examples and demos will be inserted as an ongoing process in future releases
The GovStack security solution requires a credential store as a centralized infrastructure for hosting the user account and credentials defined such that the IAM solution and other components such as the API Management and Gateway solutions can leverage them. This may end up being embedded in other solutions such as IAM or potentially implemented as a separate repository such as LDAP. - Needs alignment with Arch Document	Put details and examples for how this credentials created in security building block and used by other systems.