Key Decision Log (Identity)

Owned by Steve Conrad
Mar 03, 2023
2 min read

Out of Scope

  1. Recommendation to add a comment on general use of UIN across Europe

    1. Rational: the BB had many discussions on the use and applicability of UINs. Outcome was that not everyone was convinced that an UIN is the best approach and concerns about privacy and security were raised that were accepted by all participants.

  2. General recommendation to visualize how this BB is embedded in the whole GovStack approach.

    1. Rational: This is not something that is being done at the level of each BB but for GovStack at large. Please consult the GovStack management for such an overview which was done previously.

Next Phase

  1. Development of internal workflow

  2. Definition of internal APIs which will address the question of domain allocation as well.

  3. Implement SMART requirements to have easy identification and assessment for BB procurement purposes..

Adjusted

  1. Formatting changes to introduction

  2. Added Version History

  3. Index was added

  4. Clarifying ‘Description’ by removing text from ‘Introduction’

  5. Alignment of Glossary to

    1. Added sources where applicable

    2. Sorted by alphabetical order

    3. Added definition of ‘credentials’

    4. Added definition of ‘digital identifier’

  6. Added Cross-cutting requirements section with content from Security BB.

  7. In section ‘Key Digital Functionalities’, a clarification of the three approaches (centralized, federated, distributed) was provided

  8. Throughout the document, terminology of identity and verification was aligned to be uniform with either identity and verification BB or IDV BB

  9. The diagram depicted five APIs and five "internal sub-building blocks/ modules" which were explained. However, the sixth module "UIN Generator" was missing and adjusted now.

  10. Typing mistake on page 10 ‘Enrolment Service’ was corrected.

  11. Section 4.1 ‘Identity and Verification Building Block’ - added more content to the module ‘Federation Services’

  12. Correction of title Design sub-section: "View as a component of an Identity System” to ‘4.2 Identity System Components’

  13. Adjustment of diagram in that sub-section:

    1. To be color-coded as "gray coloured boxes" and the internal sub-building blocks/ modules as "black coloured boxes")

    2. General adjustment of the diagram to show all components including Federation Service

  14. Adjustment of diagram in section 4.3 ‘Integration with an existing Identity system’ to be clearer and to add the module ‘Federation Services’

  15. Formatting: Removed a ‘Summary Box’ that contained no information

  16. Use Cases:

    1. Added the generic use case of ‘Identity Enrolment’. This use case is also covered in the previous section of Functional Requirements since it does not require any other BB to interact with. Nevertheless, the request to complete the use cases in addition to the ‘identity verification’ and ‘cross-border recognition of professional jobs’ made sense and was incorporated.

    2. Added more context and introduction to use case 2.

  17. The section ‘8.2 Building Blocks Requirements’ was renamed to ‘Building Blocks API Requirements’

  18. All subsequent subsections to 8.2 ‘Building Blocks API Requirements’ have been renamed to include API to maintain uniformity and common naming.

  19. “Notification Services API Requirements’ amended with content.

  20. http://20.To maintain uniformity with the abbreviations used at the beginning of the section Building Block Requirements , the “O for Optional” in “*O/R/M: Optional/Recommendation/Mandatory” mentioned at the end of the Requirements was replaced by “S for Specific”.

  21. Added section and content ‘Workflow’.

  22. 10. Other Resources’ ISO/IEC reference as added

  23. Added section ‘7. Data Structures’