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

• CON-52: Consent delegationIn Progress

• 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

CON-15: Create test configuration for Consent Configuration APIsIn Progress

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?