Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Attendees

Previous Action Items

Action Item

Meeting Notes

Agenda

Presenter

Duration

Discussion

Pending action items review

Esther Ogunjimi

10 minutes

Status update

BB Leads

25 minutes

IDV BB

  • Use case

  • Finally move workflow for onboarding in the flow chart and the functional system - to make the API for IDV BB (capacity to perform authentication, to collect consent and identity attribute) these consent will be managed by the workflow. There might be no need to use consent every time there is need to get attributes

  • Added 2 more APIs - one to get attribute and service to verify 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?

Payment BB

  • Getting APIs to be tested - got input from testing team

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

  • discussion on payment for 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

***Mark implementation of test and

RBAC policy/strategy for RBAC implementation within GovStack 

Ain Aaviksoo (Deactivated)

10 minutes

  • RBAC architecture will be managed by IDV BB. Consent BB is willing to adapt to the request that will be receive as their will be authorization from the request that will come.

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

? who has the authority to ask for consent - if someone for instance has consented for medical record (there need to be such 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.

Ain - Need to have definition of role. Within the service there need to be place for consent engine to verify before processing.

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

API update & cross-BB discussion

Jaume DUBOIS

10 minutes

API/Test plan

Satyajit Suri

10 minutes

  • Having additional resources

  • Have a standardize way to prepare ----to test API and write cucumber artifact.

  • All BB lead need to be comfortable creating the …

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

Rachel Lawson (Unlicensed)

5 minutes

Release strategy/Service Taxonomy

Taylor Downs Wes Brown

10 minutes

Release Strategy for Discussion

  • Difference btw GS specification and releases.

  • GS releases will be versioned and available on Gitbook and will be specific collection of BB.

Opens

  • Blocker/Risk

All

Meeting Recording

Tech-Committee meetings-20221013_140618-Meeting Recording.mp4

Action

  • BB Leads to set up demo (mock example) application to expose the endpoint
  • Follow up with BB leads to fill out column C&D on the HR sheet
  • Invite the W3 BB Leads to TC and PC after Onboarding next week
  • Consent and IDV BB to discuss how to decentralize consent and report back to TC
  • Release strategy update from meeting from

Decision

  • No labels