Versions Compared

Old Version 1

changes.mady.by.user Benjamin Balder Bach

Saved on

compared with

New Version 2

changes.mady.by.user Benjamin Balder Bach

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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)

    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

    • Jira Legacy
      serverSystem JIRA
      serverIdf5c6bdaf-d23e-347d-a1e8-579e20a81dda
      keyCON-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

    Jira Legacy
    serverSystem JIRA
    serverIdf5c6bdaf-d23e-347d-a1e8-579e20a81dda
    keyCON-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

    • 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.