Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

TECH-654: Updates based on technical reviewDone

 TECH-665: TC action item - 11.05.23Done

• Waiting for the final read through from readers

How to define BBs consent service build in

@Ain Aaviksoo (Deactivated)

10 minutes

The whole idea of GovStack is that discrete functions are maintained in separate BB-s and not lumped into super-BB’s

Open

Open

How is consent meant to work? And will these two BB (consent and ID) work together?

Is ID BB performing consenting which might be redundant?

Ramkumar - If a consent is being signed or signed consent is being verified, can the part off ID BB be outsourced?

The gap is that consent BB is thinking of consent in the context of a document which is private to someone.

Ain - For digital management of someone’s identity, it will require fetching the data from a registry, then a data policy is expected to be created within consent BB. This consent agreement is also created within the data policy; the individual will then sign the consent agreement which will be authorised or processed through the consent BB and all data processing will then happen as planned. The consent can only be used for the purpose the consent was given and not used by others for instance government agencies that share the same database.

This question came from the testing and sandbox team to understand what these consent endpoint in the ID BB do differently or same as the endpoints that are in the consent BB

What do consent endpoint do differently in registration?

Consent does not care where certain data is being stored and how it is transferred from one database to another but, consent want to know that such actions is carried out based on prior consent and the consent is kept by the consent BB.

Steve - let’s ensure we resolve this topic soon and document the decision in the NFQ.

Status update

@Ravi Prakash V

40 minutes

• Specification 1.0 publication

  • Waiting for the final read through.

• Go through the roles and responsibilities are with the team and align on expectations.TC Process - Meetings and Responsibilities

• BBs

  • Consent BB

    • Working on the second version of the specification

    • working on the delegation of consent to address the nuances

    • Drafted a call for additional experts for consent BB. Will work with @Rachel Lawson (Unlicensed) on how to send this out.

  • IM BB

    • Ongoing discussion on PubSub group - the relations between topic, room, and event type.

    • Ramkumar - should there be one room for event messages? Multiple messages for one room? What types of event per room? (possible Use Cases)

    • Wes - suggesting a more flexible options and let the implementers decide how they want to configure things as opposed to being more prescriptive unless there are specific reasons for why we want to be more prescriptive with our guidance.

      P

  • UI/UX

    • Had workshop with Somalia to understand their needs around the UI/UX guidelines with Yolanda and Ayush

    • Working in sprints

    • Finalising draft of one the specification

  • Payment BB

    • Account mapper - finalising what is in the spec and what is being implemented

    • Park disbursement conversation ongoing

    • P2G payment - how the payment will be made? where some countries use aggregators for the bills and where is some aspect there may not be aggregator

      • How to use voucher for government services payment? the conversation is also ongoing.

• USCT use case definition TECH-225: Implement INST-1 - Unconditional Social Cash Transfer Use CaseIn Progress

  • Including the improvements and adding IM BB

• Testing

  • Focusing on finishing ID BB but yet to receive reviews from ID BB SME

  • Finalised APIs from digital registries and registration BB

• Sandbox Team

  • Working on happy flow and the journey

  • Working on creating new micro product and API mapping

  • Infrastructure presentation next week

Ramkumar - Will UIs related to BB be implemented within the Sandbox?

Meeliz - This will be built from the sandbox design and the configuration size to draw the BB interface will be done at the background but, not to show case on BB interfaces. The frontend and backend will be kept separate. Some configuration will happen in the fly during setting up the UCs in sandbox

Steve - Sandbox will largely develop and integrate their own UX and will work with them on seed and configuration data.

Wes - Native UIs, mobile application etc, being discussed like a productisation of GS, is not included in the current scope. This will be a significant expansion of the scope of what GovStack has been intended to do.

• Architecture Team

  • Merging the sandbox, adaptor and testing work. Walking through how do we start to build out specific adapters for specific candidate products. Particularly as it relates to what's needed in the USCT use case in the sandbox tomorrow.

  • The authentication flow will be discussed at the next architecture team meeting

how do we get feedback on the specs once they are published?

@Rachel Lawson (Unlicensed)

10 minutes

https://govstack-global.atlassian.net/l/cp/1KwtHyMc

• It is the responsibility of all BB Leads to keep an eye on their Jira project to ensure that any feedback received, is replied to

Candidate Products

@Steve Conrad

10 minutes

BB group to identify 3-5 candidate products for their building block. Wha are the process for identifying candidates?

It is recognised that the testing in Sandbox work is going to converge with the architecture team. Developed the adaptor concept which will allow us to take existing DPGs and build this these adapters that will map GS specs or APIs to native APIs.

We want to start identifying existing products or existing DPGs that are candidates for each of the various building blocks, take a subset of those and start to build adapters for them. This will allow us to take real products and spin them up in the test harness so we are not running test just against mock implementations but, starting to run tests against real products that have adaptors and can be spun up in our test environment and start to get real reports on what tests are passing and what tests are failing.

Secondly, we can start to identify a couple of candidate products that we can stand up in the sandbox with adapters and start to build out.

Product Roadmap

@Wes Brown

10 minutes

https://govstack-global.atlassian.net/wiki/spaces/GH/pages/111771696