2023-12-08 - Weekly Update

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 ordinary starting time at 07:45 UTC / 09:45 CET / 13:15 IST

Attendees

  • @Ain Aaviksoo (meeting facilitator)

  • @Benjamin Balder Bach (note keeper)

  • @Lal Chandran

  • @PSRAMKUMAR

  • @Philippe Page

  • @George J Padayatti

Meeting Notes

Agenda

Presenter

Discussion

Agenda

Presenter

Discussion

Kanban board + Action points from last week

@Ain Aaviksoo

skipped

General update (5 min)

@Ain Aaviksoo

skipped

Decision for HTTP headers containing PII (5 min)

@Benjamin Balder Bach

George brought this up, as it’s an important parameter for API endpoints and currently it’s loosely specified because we were waiting for alignment between building blocks, like ID. Let’s quickly decide if there is any changes to be made to putting “Individual ID” in HTTP headers.

Decision: We will adopt the intention by giving the HTTP header a specific name, such that DDX and compliance tests can make use of this. “X-ConsentBB-IndividualId” is chosen.

Are there any risks associated with missing compliance tests wrt DDX tests?

@Ain Aaviksoo

(background: testing team is still clogged up in work, so we want to ensure that there aren’t blockers or progress being hindered)

WG can start defining Gherkin scenarios. But we need to coordinate their implementation. These tests are part of proving compliance of the DDX solution.

Is there a need for a sign-off on a specific date with regards to compliance tests?

The WG is committed to writing scenarios and coordinate between the DDX solution and the test harness as it matures.

Discussion about the definition of consent in our specification vs. implementation in DDX

Everyone

Ain has re-reviewed the specification and want to conclude on where we are in terms of the future roadmap and what our current working definition of consent looks like. The text here summarizes this: Future Considerations (Consent)

Lal: The workflow for individuals to make decisions is with the application. However, the Consent BB should be avoiding “blanket checks”.

Philippe: “Intend and purpose” are the actual phenomenon hiding behind “legitimacy”. The BB can not measure the context in which a request is being made.

Philippe: There is no understanding of what “personal data”, it is fluent, by changing data they can become personal.

Current state of our BB is doing point “B”, but lawful basis and extended consent are problematic at this stage. They change from country to country and topic to topic (i.e. medical is special).

Ain had to jump out, so we will continue this discussion next week

Dr Ramkumar had an additional question about consent and data structures: What specific fields of data is consent addressing? Can we govern that specific data fields require consent in themselves. For instance, what if an individual gives away someone else’s personal information?

Lal responded. The data consumer or data controller needs to take responsibility for the data that they are controlling or processing in a way where consent is obtained from the correct parties in a legally appropriate way.

On the topic of usage and illustrating the responsibility of the application and organizations involved, Philippe made an example where purpose is “research”, but that “biological weapons research” wouldn’t be understood by an individual as normal research.

Offline consent

postponed to next meeting

We had to postpone this. Note that we’re trying to figure out a terminology here. “On-demand” consent was used to emphasize the risks of this kind of thinking, but “offline consent” will help us capture the broader nature. Everyone is encouraged to think about terminology

 

 

 

 

 

 

 

 

 

 

 

 

Consent delegation

skipped

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?

New Action Items

Action Items from previous meetings

@Ain Aaviksoo 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)
@Benjamin Balder Bach Prepare fixtures review for Lal
@Ain Aaviksoo will coordinate with Sandbox team - note that Lal is requesting and end2end use case.
@Ain Aaviksoo Organize a coordinating meeting with Testing team
@George J Padayatti Open a PR with Dockerized setup in consent-bb repository
@Ain Aaviksoo Call for a discussion meeting regarding “on-demand” OR multi-party consent workflows (need to choose which topic?)

 

Decision

  1. We’ve decided to add the Individual ID to HTTP headers in our specification and call them “X-ConsentBB-IndividualId”