Agenda

Presenter

Duration

Discussion

Technical Reviews of BB specs

@Steve Conrad

10 minutes

Architecture team to review Wave 3 specifications: Target Friday August 11 to complete reviews

Update on review process:

• UI/UX - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/Xygp83qW0E147CCaqsI0/ - reach out to Yolanda/Ayush/country team for review, as well as TC members and Gofore (Artun and Jonas)

• eSignature - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/ZpypLvJhKezO3prCNVTS/ - @Aare Laponin

• eMarketplace - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/ - @Aare Laponin

• GIS - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/hkgz6Ka97bI1OCzGXUgW/ - content to be completed next week.

• Cloud Infrastructure will not be part of Wave 3 and Sept. release

Next steps - once reviews are complete, Wes can create Jira issues for required changes and create Epic to track all tasks. For now, keep comments in GitBook.

Commenters should flag changes as ‘Required’ for anything that must be changed prior to release.

Generic vs use-case specific components

@Nico Lueck

10 minutes

Use Case Dependent

• Frontend

• Backend Application (the app managing the API calls)

• BB Emulator (because specific APIs and data to enable the one use case)

• Repositories (because might contain Use Case relevant data)

The goal should be to make the above as small as possible - and eventually have shared components that can be used to construct the frontend and backend applications

Generic (might be adapted to country specific context but not for each use case)

• Adapter (per product/DPG)

• Test Harness Scripts

• BB Configuration file

• BB candidate software

• Repositories (because might contain generic core data)

• Service Blocks/Workflows (eventually)

This can be documented along with the GovStack overall diagram/overview

Finalize UX Switching

@PSRAMKUMAR

5 minutes

Finalize document and make plans to disseminate to TC and BB groups

• Steve to update Confluence document with latest changes from Ramkumar

  • Refactor to show as sequence diagram. Use ‘application’ and ‘auth services’ nomenclature.

  • Ramkumar to update to implement API call to receive token to avoid race condition

• 4th option is the preferred option. Implementers may choose to implement other options if they are suitable. There may be UX flows that do not require the 4th option and implementers can choose a simpler path to handoff UX.

GERA Update

@Aare Laponin @PSRAMKUMAR

15 minutes

Update on changes to GERA document and progress/next steps

• Arch team is not actively engaged in changing this document.

• Aare working to develop a simple overview/reference document - introduction, definitions, context, reference architecture, implementation guidelines

Working draft:

https://onedrive.live.com/view.aspx?resid=7B252BA6CB083436!9402&ithint=file%2cdocx&wdLOR=c6150EBA7-4B67-A140-9088-2C81F864DEFA&authkey=!ADG46QZQKE_VrJ0

We will need to decide how to publish or whether we can bring back to Open Group.

Could publish in GitBook as part of the spec/release. We will try to target as a part of Sept release - after work is done by Aare, will have architecture team review and move into GitBook.

Can we find another name for this document, so we can release it as something different and ‘sanctioned’ by GovStack:

What is our messaging around the current Open Group GERA document?

Review overall diagram

@Steve Conrad

10 minutes

Overall GovStack Architecture Diagram

Include in non-functional requirements, along with a description of an overall GovStack implementation (content from above)

Highlight what may be done by local system integrators - SI may use a registry that is not a GovStack BB, but rather a local BB

Reach out to comms - to add color, make it easier to understand/digest

Steve to post in architecture channel for comment.

Capabilities/Service Blocks

@Wes Brown

15 minutes

Review service block (capabilities) template

Future topic - Fall 2023

Manage Access Authorization to BB APIs

@Jaume DUBOIS

30 minutes

• Types of accessors checked (human, back-end systems, apps or browser, robots, hardware, ..)

• Granularity of access control (Building block, module, API, single API service, single API service for specific tenant or data)

From Technical Committee Meeting:

BBs should not own RBAC - the calling applications are responsible for it. 

Are we using token based authorization within the request to BB?

How to get candidates bypass its own RBAC?

1. Superuser access to be given when merging with IM backend?

2. Or control to switch off existing RBAC in target BBs

3. option to have api token registered in IM at max permission level for specific member entities

4. come up with a concrete example for this case