2023-09-08 - Weekly Update

Sep 8, 2023

About this document: Agenda and notes are kept in the same document, a separate copy of the document is maintained for each meeting. Please add agenda points before the meeting. Action items created in previous meeting and all other unresolved action items are kept in the document. Please tick off any completed items.

Meeting link: https://meet.google.com/rsf-cqaq-eyq at 07:30 UTC / 09:30 CET / 13:00 IST

Attendees

  • @Ain Aaviksoo (meeting facilitator)

  • @Benjamin Balder Bach (note keeper)

  • @Lal Chandran

  • @PSRAMKUMAR (out)

  • @Philippe Page (out)

Meeting Notes

Agenda

Presenter

Discussion

Agenda

Presenter

Discussion

Kanban board + Action points from last week

@Ain Aaviksoo

skipped

Continuation from last week’s meeting “consent agreement” vs “data agreement”

@Lal Chandran

Lal presented the consent of “data agreements” and why it’s important to work with this distinction, rather than simply “agreement” or “consent agreement”.


”data agreements” seek to deal with data, but what about other situations of consent.

”Power of attorney” may be important, but so is distinctions. So it’s possible to choose different paths for “data agreement”, either making it a specific type of agreement with other future alternative agreement types possible. OR design the entire spec to only assume data agreements.

Tuesday meeting

 

We’ll do a light bridge between GitHub and Jira

We will accept input from Jira and will ensure the right manual proxying

Keep the overhead minimally.

Lal & team will put some major documents around milestones in Confluence.

What will go into the next spec

 

Minimal changes to API spec

”Onboarding” of data sources and consumers hasn’t been handled. We need a component that can be used by the data source to understand data consumer requests.

We will have focus on critical changes, will have several meetings next week.

Review of example data

@Benjamin Balder Bach

Will be introduced to Lal on Tuesday’s meeting. @Lal Chandran will review and add comments and ideas to fixtures, will be implemented and part of the new release.

DDX Consent BB implementation open topics/questions:

skipped

  • Solution and adapter, are they separated?

  • Are you aware of the bb-consent/examples/ structure?

  • Are you aware of GovStack UX Guidelines that are published?

  • What to do with APIs that aren't part of GovStack specs - expose them in the same structure?

  • What do we need to accommodate in the Consent BB planning? What "best-practice" guidance is found for building solutions for GovStack?

  • What sort of workflows are great, for instance for building consent. How will engagement with other BBs work? Will you be able to work on this aspect?

Consent delegation

skipped

Review necessary Gherkin scenarios to implement

@Benjamin Balder Bach Skipped

https://govstack-global.atlassian.net/browse/CON-15

Spec 2.0: Unfolding new roadmap items

Skipped

 

New issues

@sasi

parked for future meeting

  • What do we expect other BBs that call Consent-BB to store?

  • When do we like to use Consent-BB and when do we not expect this? (This should also be know to the auditor.)

Discussion: How shall we address such matters, which do not fit into specification format?

New Action Items

@Benjamin Balder Bach Prepare fixtures review for Lal

Action Items from previous meetings

@Ain Aaviksoo (Deactivated) consider if the decision to have “external ID” and “external ID type” referencing Individuals is relevant for the Key Desicion Log (if it’s not already there)
@Philippe Page will finish the initial descriptions and commit himself to the ones he feels appropriate

 

Decision

  1. Previously, we have been writing “Agreement” and we will start using the term “Data Agreement” in the specification. We will make space for alternative future types of agreements in our spec.