Nov 4, 2022

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

Attendees

• @Ain Aaviksoo (Deactivated) (meeting facilitator)

• @Philippe Page

• @Lal Chandran (n/a)

• @Benjamin Balder Bach (weekly note keep and time keeper)

• @sasi (n/a)

• @PSRAMKUMAR

• Maksim (n/a)

Meeting Note

Notes from group reading

• Notable features/aspects

  1. Consent workflow is “asynchronous” - if consent required Notification system for individuals

     • Consenting is facilitated via Citizen portal that also provides universal UI for the signing of consent (potentially and equivalent to Registration BB within GovStack);

     • the group has a lot of worries about asynchronous consent, how is delegation handled, who is requesting consent and what should the system respond;

     • relevant use-case to consider would be Mother initiating registration remotely (i.e. not being physically present at the Healthcare Provider) and then a relevant consent workflow is prompted after the Mother herself has initiated the registration (or other) process

  2. Consent manager operates via “Security server”

     • this should be seen as a combination of Information Mediator BB + Workflow Management BB in the context of GovStack

     • mere “security server” managing consent workflow does not seem compatible with Consent BB specification

     • the role of Workflow Management BB for Consent BB requires clearer understanding

• Consent Management Proxy - what does it handle, are there performance issues from the real world that decide where responsiblity and data services end up?

• How is correlated data handled with this type of configuration? Who says that the “consent” is valid?

  • Elaboration of how it works when MCC adds purpose to existing Consent

• Would the Cybernetica Consent Management solution put a generic UI into the MCC flow?

• It seems that if the “security server” approach would be clarified, such a solution would be compatible with Consent BB (and vice versa - Consent BB spec seems to be relevant for real world solutions)

• An issue discovered - How do we handle the “paradox” that

  • we need a signed version with state:signed, but should we change the state to “signed” in order to have a signed Consent Record that also says “signed”?

  • We need to be able to verify the correct has of any Consent Record

  • Perhaps worth learning from the Cybernetica’s solution and elsewhere, how this has been handled

Action Items

Action Items from last meeting

Decision