text: 2018-07-05 Meeting notes (CR) - Archived Groups - Kantara Initiative
  2018-07-05 Meeting notes (CR)
  Created by Andrew Hughes, last modified by Jim Pasquale on Dec 12, 2019
  Sylvester Mbagwu
  John Krogulski (WIDA)
  Meeting was not quorate
  Participant Roster (2016) - Quorum is 5 of 8 as of 2018-02-22
  Iain Henderson, Mary Hodder, Harri Honko, Mark Lizar, Jim Pasquale, John Wunderlich, Andrew Hughes, Oscar Santolalla
  Director's Corner: 2018: June
  There is a new wiki page that will hold all the known implementations of Consent Receipts - Please update the page or inform Andrew of your implementation.
  Planning a Member Plenary meeting October 26-ish San Francisco (Friday after IIW)
  Are there specific cross-group items you'd like to propose to work on?
  40 min Interoperable Consent Receipt demo at MyData Conference Andrew
  Andrew walked through the sequence diagram.
  Richard - the 'Export' consent receipt might be too disruptive to the user - maybe
  John Krogulski - what data formats? A: It's set out in the specification
  Mark - should we be using JWT for transfers?
  A: This might be a complexity that we should incorporate in later interops
  A: This is a complexity versus future-proofing question... ANDREW to ask the list/implementers
  ACTION: All to post comments to the wiki page about the sequence diagram, questions, clarifications etc.
  Ready to draft a user story - aiming for delivery on next call
  Tom - there are prior activities that are not showing on the sequence - the Data Subject has to be identified to the Controller and Platform including any consents
  Mark - the "initial consent flow" - the sequence is not showing the bootstrapping sequence - the sequence is showing the ongoing interactions
  ACTION: Andrew to annotate with prerequistes and assumptions of user already being set up
  ACTION: to document the technical flows of Consentua in the context of the interop demo sequence
  Sylvester's Action item:
  A receipt reader is an application that parses (reads) consent receipts automatically. A reader only handles consent receipts in it's machine readable format and is a component of some automatic process.
  Receipt Viewer
  A receipt viewer is an application that a human uses to interpret the contents of a consent receipt. An application can only be considered a receipt viewer if it presents receipt data in a human readable form.
  Receipt Dashboard
  A receipt dashboard is an app used by humans to store and manage consent receipts. A user can use their dashboard to perform batch operations on multiple receipts at a time.
  ACTION: All to comment on these starter definitions, on list (note that the text above has already been edited)
  2018-07-12 same time, same number
  GOAL IS TO HAVE ALL DEMO PARTICIPANTS JOIN THE CALL TO WORK OUT ANY MAJOR ISSUES
  From 2018-06-28
  Discussed Kartik's v1 of the sequence diagram
  Park: the discussion about 'viewer/reader/dashboard' and the differences in functionality that those terms encompass
  Has anyone played with the 'sand' demo app? URLs to follow by email
  First part of the demo:
  Data Subject interacts with Organization A and as a result, a consent receipt is created and shown to the Data Subject. The consent receipt is stored in a place that is known to the Data Subject.
  Second part of the demo:
  Data Subject starts their preferred app which they normally use to view and manage their consent receipts and sees a list of consent receipts that are in the place referenced from the first part of the demo. Data Subject clicks the new consent receipt and the contents are displayed.
  ACTION: Mark/Sylvester to write functional descriptions of the 'viewer/reader/dashboard' concepts
  From 2018-06-21 call:
  John walked through the draft scenario
  Mircea: why would the receiving org need to generate a new CR?
  A: Depends on the interpretation of Article 20 implementation
  Jim: digi.me's consent feature requires that the data processor notifies the user on downstream sharing
  Karik: Trunomi allows counterparties to be defined and data sharing rules defined up front. PSD2 scenarios - has 2 consents that are tracked - 3rd party doing payments on behalf and the financial institution
  ACH: Would it make sense to just do the simplest thing: one data controller mints a CR and a different org displays it.
  Richard: important to do display and that the back end system is following the CR instructions
  Jim: digi.me has started work to 'export' a CR artifact. The user might be notified of sharing event.
  John: starting to think that we should disconnect the demo scenario from any specific regulatory requirement - this should stay a technical demo
  Robert: agrees - show what you received is what was sent - and show multiple receipts that display in the same way
  ACH: related that people in unconference sessions are capable of imagining potential uses of CRs - we need to show the simplest functions
  Kartik: conceptually makes sense - questions on the details about how multiple platforms will play
  Mircea - need to decide on which systems take on what roles in the demo - which ones create CR, which ones consume & display
  Richard: in principle it is OK - what does it actually look like to a User - the UX and concept of a CR moving from one place to another - there is no metaphor for this yet
  Oscar: does not have viewer yet - so this would help to have some else's viewer to use
  Mark: is the CR moved directly by the back end or are the actions done by the User.
  ACH: has lined up a mobile operator as a issuer of CRs - but they have no viewer - they need the user to use someone else's viewer
  ACH: need to do a storyboard
  Robert: the metaphor should probably be the same as physical receipt management - one place to view them
  ACTION: Richard to sketch a story board for this
  ACTION: Kartik to ask questions around how consent management platforms - send to email - includes sequence diagram
  Mircea - is each consent receipt unique? and should it stay at the originator org? then the only thing transfered would be the CR id?
  ACTION: Jim - to list some of the high level activities that digi.me is undertaking
  Mark: OpenConsent is planning to have a Viewer by August
  Possible distinction: A Viewer - look at CRs one at a time. Dashboard - look at multiple CRs and act on them.
  From 2018-06-14 call:
  Jim: any project wanting to participate in the MyData consent receipt interop demo - we need you do do a mapping against the CR fields - there is a spreadsheet!
  Need to ensure that the Use Case spotlights the user-centric approach. A motivator to show vendor-vendor interop is to demonstrate industry resilience.
  Since the CR will contain personal data (and probably sensitive data) we must avoid giving the impression that we are unware of risks and anti-patterns.