Key Decision Log (Security)

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.