Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.