Attendees
Previous Action Items
Action Item |
---|
|
Meeting Notes
Agenda | Presenter | Duration | Discussion |
Pending action items review | 10 minutes |
| |
Status update | BB Leads | 25 minutes | IDV BB
There might be no need to use consent every time there is need to get attributes as the consent and be stored and use offline Workflow BB
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;
it is important to have these clear artifact in a clear place and sharable. Seems where the priorities are with different BB. Payment BB
|
RBAC policy/strategy for RBAC implementation within GovStack | 10 minutes |
Taylor - no need to reinvent the wheel but can leverage on similar solution already built that suites GovStack need
Ramkumar - The role based access control will be left for BB to decide what will be allow and disallow. Jaume - there will 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 | 10 minutes | Added 2 more APIs - one to getting attribute and service for verify attributes as its 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 veritable; and can be stored in different place e.g. wallet or the functional system 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 tie to consent policy to define set of inscriptions to describe the purpose e.g. GDPR legal framework. This allow 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 | 10 minutes |
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 in example/mark | |
How/where to manage roadmap | 10 minutes | ||
Adding a YouTube channel for storing meeting videos across multiple formats plus other videos Comms etc. may have — for TC approval | 5 minutes | ||
Release strategy/Service Taxonomy | 10 minutes | Release Strategy for Discussion
a. GovStack releases - specification will 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. This 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 - suggest 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
| All |
Meeting Recording
Action
- BB Leads to set up the examples with the demo application - if they do not have DPG identified. Demo application is required to expose the endpoint. (Demo mock example) Satyajit Suri and all BB Leads
- Follow up with BB leads to fill out column C&D on the HR sheet Esther Ogunjimi
- Invite the W3 BB Leads to TC and PC after Onboarding next week Esther Ogunjimi
- Consent and IDV BB to discuss how to decentralize consent system which does not depend on online connectivity of a single service and report back to TC - Ain Aaviksoo (Deactivated) Jaume DUBOIS
- The PR (pull request) on the the consent BB have their mark implementation of a theoretical consent application is called “demo” but should be call “mark” - Ain Aaviksoo (Deactivated) to look at the PR.
- Account mapper keeps the ID with payment discussion will be planned with Jaume (IDV BB) to better understand the API - Mauree, Venkatesen
- Have focus discussion on role based access control for consent BB and feedback to TC - Ain Aaviksoo (Deactivated)
- Satya, Wes and Taylor to discuss sandbox request to the vendor and feed back to TC - Taylor Downs
- Get all BB to create mock demo example - Satyajit Suri
- Release strategy update meeting