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	https://govstack-global.atlassian.net/browse/CON-52 Where is the relationship between individuals stored? The application is aware of it? Another BB is aware of it? Auditing should be able to verify it
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

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.