Agenda

Presenter

Duration

Discussion

Technical Reviews of BB specs

@Steve Conrad

10 minutes

Update on review process:

• UI/UX - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/Xygp83qW0E147CCaqsI0/ - Review complete and issues created

• eSignature - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/ZpypLvJhKezO3prCNVTS/ - @Aare Laponin. Review Complete and issues created

• eMarketplace - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/PUIGDILlDRSOB6K47k6e/ - @Aare Laponin. Review Complete and issues created

  • Note: Arch team has questions on the scope of this BB. Taylor to raise in eMarketplace Slack channel.

• GIS - https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/hkgz6Ka97bI1OCzGXUgW/ - Review done and issues completed

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

Wes to review Wave 3 BBs to ensure that they are aligned to the template.

Ramkumar to work with Wave 3 teams to get complete list of contributors.

@Steve Conrad - Set up meeting with eMarketplace so that we can articulate the current and future scope, as well as what procurement functionality should be included (either current or future)

Specific question for Architecture team: MKT-154: Service APIs Section - Technical Review for Non-REST APIsDone

PAERA Update

@Aare Laponin @PSRAMKUMAR

15 minutes

Update on changes to PAERA document and progress/next steps

Working draft:

https://onedrive.live.com/Edit.aspx?resid=7B252BA6CB083436!9551&wdPid=5887d621&authkey=!AC4bdYfdJIaKi8M

Ready for review and comment (Sections 1-3). Steve and Wes to review.

Need to decide where this lives for the upcoming release (GitBook, linked, PDF)?

• Put summary/overview in GitBook (in cross-cutting section) and then link out to full content (ie. PDF in GitHub)?

Prioritize future topics

@Steve Conrad

20 minutes

There are several future topics below. We need to identify what are most critical for architecture team to work on.

Aleks: Size of Building Blocks, ie. MOSIP - large products can’t really function as Building Blocks. How do we better identify candidates?

Taylor: Creating a vision/picture of how we expect GovStack to implemented. What do we expect GovStack users to do? Identify products, create adaptors, prototype? Create citizen portal? Is GovStack just used to support RFP processes?

Trev: Define user personas and user journeys

Ensure that we have the guidance/resources for various users to actually implement these journeys

Taylor: Architecture team can then identify the ways that we need to communicate better. Be better at explaining GovStack and how it works and how it serves different user personas. High quality content around why is GovStack valuable - still technical, but more big picture.

Aleks: Have to be able to demonstrate real use cases in sandbox. We have to prove out that this can be done.

Ramkumar: More country engagement - they will identify questions/gaps.

Should we define/mandate a central portal for GovStack? How do we manage SSO/IAM across multiple use cases? Need to engage more with Sandbox team to ensure that what they are implementing is aligned with GovStack architecture.

• Can arch team or BB groups contribute directly to sandbox to validate?

Generic adaptor building block

Trev: another pass through the security spec

Articulating the tradeoffs between specificity and more generalized approaches. How do we better position ourselves as technology agnostic (and should we)? Provide different examples of implementations using different stacks?

• Deciding where on the specificity spectrum we want to live

Rough groupings/priorities:

1. Alignment with Sandbox. Ensuring that approach to SSO/IAM and implementing use cases is aligned with architecture

2. Defining user personas and journeys - outputs would be overall messaging, providing high-level guidance. How does GovStack work to deliver value.

3. Adaptor concept/Adaptor BB

4. Providing guidance on specific questions coming from country engagement

5. Articulating different levels of building blocks - foundational, functional, application.

6. Example implementations - having BB groups work on them.

2,4,6 are oriented around giving inputs to other groups (country engagement, BB teams). Architecture can/should do more definition around #2 (not just giving guidance)

Future Topic - Capabilities/Service Blocks

@Wes Brown

15 minutes

Review service block (capabilities) template

Need clear definition of distinction between building block and service block.

Future Topic - September

@PSRAMKUMAR

Go through key learnings from Egypt deep dive and Kenya roadshow and map out how to address them in the architecture documents

• Do we need an adaptor Building Block?

• How do we align terminology with governments who may have a different view of particular BBs or services. Are there better ways to quickly agree on terms?

• IM questions

  • Large data transfers through IM. How do we secure access to those resources?

  • Using IM on intranets

  • How do we handle IM failures?

  • Sandbox uses auto-approval process. Document that this is not recommended.

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