Agenda

Presenter

Duration

Discussion

Pending action items review

@Esther Ogunjimi

10 minutes

• Benjamin of Consent team will be supporting testing and integration with 90% of his time.

Status update

BB Leads

25 minutes

IDV BB

• Move workflow for onboarding i.e. (authentication, collection of consent and collecting attributes) into flow chart and the functional system - to make the API for IDV BB have capacity to perform authentication, capacity to use token and alias, capacity to collect consent and identity attribute. After the consent is received, these consent will be managed by workflow. ID of the consent can be kept in the functional system and make use of later by the individual, where there is need to collect new attributes or could be stored in consent.

There might be no need to use consent every time there is need to get attributes as this will be stored and used offline

Workflow BB

• Cucumber conversion in progress and running cucumber locally on cumunder.

• Working with other BB Leads with test strategy and planning

• Slow down on circleci running cucumber, so test can pass locally and not on ci.

Ramkumar - there are similar dependencies from other BB team. it will be useful to invite the BB Leads deputies to be part of the training Taylor is leading. Satya to invite Tamberth to this meeting as he is building cucumber scribe in silo.

Taylor - suggested the Engineers that will be shared across BBs, should be part of the testing office hours - where they can bring problems with test implementation group.

Get the BBs to focus on;

• Mark implementation of spec

• Having actual running test

it is important to have these clear artifact in a clear place and sharable. Seems where the priorities are with different BB.

Payment BB

• Getting APIs to be tested with input from testing team.

• Will be looking at the payment scheme for countries without payment switch in place.

• Met with Ingmar of payment BB to discussion use case related to the postpartum and mother registration payment. The concept of registries was also touched on, where unconditional social cash transfer and conditional social cash payment. Two types of onboarding (physical and digital/remote) was also discussed - what will be kept in digital registries.

RBAC policy/strategy for RBAC implementation within GovStack 

@Ain Aaviksoo (Deactivated)

10 minutes

• The RBAC architecture will be managed by IDV BB. Consent BB is willing to adapt to the requirements that will be receive as there will be authorization from the request that will be received.

Taylor - no need to reinvent the wheel but can leverage on similar solution already built that suites GovStack need

• ? who has the authority to ask for consent - if someone for instance has consented to check medical record, the respond has to be managed (there need to be such a service that will be managed by IDV BB).

Ramkumar - The role based access control will be left for BB to decide what will be allowed and disallowed.

Jaume - there will be several needs for multiple roles (son, doctor and students).

Ain - Need to have definition of role and should be captured in the data agreement. To ensure only the authorized people can see the data. There also need to be within the service a place for consent engine to verify the ID consent before processing.

This will be resolved during the practical build up of use cases. It will be resolved on case by case bases.

API update & cross-BB discussion

@Jaume DUBOIS

10 minutes

Added 2 more APIs - one to getting attribute and service to verify attributes as it is being used currently with the postpartum use case.

Ramkumar - How to secure the Decentralized consent capacity to avoid duplication?

Jaume- consent should be signed and verifiable; and can be stored in different places e.g. wallet or the functional system that can store outside.

Ain - Consent framework is built for consent record to agree with signature for a consent agreement; then the consent agreement has to have all the component for the purpose of data processing. The consent agreement is tied to consent policy to define set of inscriptions to describe the purpose e.g. GDPR legal framework. This allows to link consent record (which is the signature aspect) with consent agreement (which is the consent of what has been consented) with data policy to which this happen.

How do you verify consent record against the consent agreement for audit purpose? Does the verifying require online connection?

Do you require additional service API to verify?

Jaume - When consent is given for instance the health section, it is now the ownership of the health sector with expiry date.

API/Test plan

@Satyajit Suri

10 minutes

• Taylor is doing great work in supporting test team on test implement.

• Having additional resources to pick up work pace

• Working on having a standardize way to prepare broken future files for test APIs and writing cucumber scripts and implementation steps. These will be done with the first UC (postpartum) independently.

• All BBs need to be comfortable creating the mock demo example to expose the endpoint. Then we can have pipeline of test cases and build more use cases.

Ramkumar - all BBs pick one API and do same for their BB they already align with. To determine how test readiness, stabilizing the process, tool scripts and candidate API.

Taylor - The next step picking open API spec to get phyton mark server up and runing for the open API spec. Taylor has helped in copying Benjamin folder into here.

How/where to manage roadmap

10 minutes

Should be stored on OneDrive GovStack OneDrive

Ramkumar - suggested to shutdown Google Drive. Have one place to track all TC action item.

Adding a YouTube channel for storing meeting videos across multiple formats plus other videos Comms etc. may have — for TC approval

@Rachel Lawson (Unlicensed)

5 minutes

Release strategy/Service Taxonomy

@Taylor Downs @Wes Brown

10 minutes

Release Strategy for Discussion

• Difference between releases of GS specification will take place at two levels

a. GovStack releases - specification will be released for all of GS. GS releases will be versioned and available on Gitbook and will be specific collection of BB.

GovStack 1.0 will be collection of specific versions of BB specification releases or updated version. These are versions for specifications at GS level and individual BB.

b. Deployment - will be carried out at different time using various parts of GS. The vision is for software deployment around the world to implement GS specifications or follows GS model or adheres to GS API set. The only example available for now is for postpartum.

Ramkumar - suggests to have a different example with sandbox. Jake and Hani should be brought into sandbox conversation.

Taylor - The GS specification versioning should be a product lead decision while the individual BB versioning should be technical lead decision.

Wes - instead of GS version, it should be the platform version for it to be inclusive. PC and TC should support in writing the specification for sandbox.

Jaume - GS version 1.0 is set of BBs integrated and tested together, they are guaranteed to be working together on the set of use case.

Wes: There is need for PC and TC to communicate more as regards sandbox.

Opens

• Blocker/Risk

All