2023-02-14 - Weekly Update
- Benjamin Balder Bach
Feb 14, 2023 RESCHEDULED
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 11:00am CET
Attendees
@Ain Aaviksoo (Deactivated) (meeting facilitator)
@Philippe Page
@Lal Chandran (out)
@Benjamin Balder Bach (weekly note keeper and time keeper)
@sasi (out)
@PSRAMKUMAR (out)
Meeting Note
Agenda | Presenter | Discussion |
|---|---|---|
Action points from last week | @Ain Aaviksoo (Deactivated) |
|
Updates from TC meeting (fixed) | @Ain Aaviksoo (Deactivated) |
|
Gherkin scenario writing discussion | Everyone | Specific questions discussed from Ain’s work on Gherkin Scenario drafting document |
Payment Use-Case | @Ain Aaviksoo (Deactivated) | What are consent-related aspects of the Payment UC? |
Scope and service registry? | @sasi @Ain Aaviksoo (Deactivated) | What are our next actions on registering required scopes for BB services? |
“Consent management” definition | @Ain Aaviksoo (Deactivated) | We renamed “Consent Management BB” to “Consent BB”. Is there a useful definition of “consent management” that we can apply? |
Questions discussed from Gherkin scenario writing
Notekeeper: Ain originally asked some fundamental questions around defining the trust of parties which the Consent BB interacts with. It could seem that we need to define these relationships and also the liability of the Consent BB in regards to verifying for instance an individual and the Agreement that an application stores.
The following are a reflection of the questions asked (please pitch in @Ain Aaviksoo (Deactivated) )
Q1: Is the information that we have verifiable? Can we archive "any" kind of consent and will just trust the calling application? Q2: There is no foundational ID that works across all building blocks. It may sit in IDBB.
Q3: 360 profiling, we to know how and if we can perform our auditing and revocation of consent as is necessary, despite the anonymized individual IDs.
Q4: About individual rights: To withdraw, to be forgotten etc... they make the Consent BB an authority to other BBs, saying "this consent is now withdrawn". You must do ABC. We envisioned PubSub for this, but there is a need of trust here, too.
Q5: Do we need to quickly define The Application or whatever trusted entity that we allow to store Consent Records and which Agreements the application owns?
@Philippe Page comments on Q5: Who is part of the "club" can be decided by Data Governance Administration, there is an ecosystem where entities have decided to trust each other. This could be decided by The Mediator.
Benjamin: Consent BB just needs to store the configuration of what "the club" can do, for instance which Agreements they are eligible to store and revoke consent for. A bit like RBAC.
New Action Items
Action Items from previous meetings
Decision
- Consent BB decides to restrain from redesigning API endpoints in order to “bundle” or “optimize” sequences of calls. Unless the TC eventually comes up with a stance of this.