Page Comparison

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

• Use case

• Finally move Move workflow for onboarding in the 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 the workflow. 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

Ramkumar - Decentralized consent capacity?

Jaume- consent should be signed and can be stored in different place e.g. wallet..

Ain - Consent record agree signature for consent agreement for data processing, the consent agreement is tie to consent agreement to define set of inscription - to describe the purpose e.g. GDPR legal framework. To link consent signature and consent agreement with data policy to which this happen.

How do you verify consent signature for the purpose of audit?

Do you require additional service to API to verify?

Jaume - How can we decentralized consent?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 - got with input from testing team.

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

• discussion on payment for Met with Ingmar of payment BB to discussion use case related to the postpartum and mother use cases underway

• Account mapper keeps the ID with payment discussion will be planned with Jaume (IDV BB)

Workflow BB

• Running cucumber conversion locally on cumunder

• Working with other BB Leads on test strategy

• 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 request requirements that will be receive as their there will be authorization from the request that will comebe 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 . Within the service there 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.

It This will be resolved during the practical build up of use cases and . 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 Have to pick up work pace

• Working on having a standardize way to prepare ----to test API and write cucumber artifact. All BB lead 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 btw between releases of GS specification and releases. 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