2023-09-01 - Weekly Update

Sep 1, 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 (abstained)

  • @Lal Chandran

  • @PSRAMKUMAR (abstained)

  • @Philippe Page (abstainied)

Meeting Notes

Agenda

Presenter

Discussion

Agenda

Presenter

Discussion

Kanban board + Action points from last week

@Ain Aaviksoo

skipped

DDX Consent BB implementation and 1st phase deliverables

@Ain Aaviksoo @Lal Chandran

Updates from (presumably) the tech meeting that happened Wednesday/Thursday.

Discussion on DDX Consent 1st phase deliverables:

  • @Ain Aaviksoo has added comments and suggests foor approval

  • @Lal Chandran added that the spec can end perhaps will be updated later as more details will be carved out.

Discussion on “consent agreement” vs “data agreement”

  • The differentiation comes from pre-GDPR vs post-GDPR understanding of “consent” - it used to be very broad, but in GDPR was deefined narrowly with other legitimate data processing cases legally defined using different terms.

  • “Data agreement” embraces all legitimate data processing cases. “Consent” is part of them

  • In real life, mostly “consent” (as GDPR defines it) driven data processing is intertwined with other legitimate data processing situations (eg fulfilling a contract or public duty). Hence, from practical purposes it makes sense to handle them in the

  • UX and UI of DDX Consent solution support this approach

  • For example:

    • “Data agreement” contaings ALL legitimate data processing instances, some of which can be opted out (consent-based) and some cannot (fulfilling the contract or public duty)

    • “Consent record” signes all these instances as one “signed agreement”, that means both the consent-based approvals and other legitimate data processing approvcals

    • If individual opts out of some earlier approved data processing (eg sending marketing emails) then the new “data agreement” is signed into “consent record”

  • Needs discussion how and when we introduce “data agreement” in GovStack spec instead of “consent agreement”, since it might cause confusion if not done carefully and conscisely

  • “Data agreement” approach is aligned with ISO 27560 (1st public version in August 2023)

 

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

Action Items from previous meetings

Schedule tech meeting @Lal Chandran
Schedule / update agenda for next meeting with remaining questions from this meeting’s discussions @Benjamin Balder Bach
@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