2018-07-19 Meeting notes (CR)

Date

2018-07-19

Status of Minutes

Approved

Approved at: 2019-12-12 Meeting notes (CR) DRAFT

Attendees

Voting

• Andrew Hughes
• Oscar Santolalla
• Jim Pasquale
• Mark Lizar
• John Wunderlich

Non-Voting

• David Turner
• Chris Cooper
• Bev Corwin
• Sylvester Mbagwu
• Sal D'Agostino
• Colin Wallis
• Tom Jones

Regrets

• Richard Gomer
• Kartik Venkatesh

Quorum Status

Meeting was quorate

Voting participants

Participant Roster (2016) - Quorum is 5 of 9 as of 2018-07-12

Iain Henderson, Mary Hodder, Harri Honko, Mark Lizar, Jim Pasquale, John Wunderlich, Andrew Hughes, Oscar Santolalla, Richard Gomer

Discussion Items

From 2018-07-12 call:

1) Story board discussion - Richard

https://gist.github.com/RichardGomer/14fccfb4c590d6b1285422215cd6e3b5

• Diagram A: "Get consent receipt"
  • 
  • This is the crux of the demo
    • How does the user know they have a CR? 
      • What will a user experience when this happens?
      • Option: make CRs optional to the user (ask them if they want a CR at all)
    • How do they know what to do with at CR?
• Diagram B: "List Consent Receipts"
  • 
  • The location of this diagram is not specific (on purpose)
  • Two parts here:
    • 1) for any given Data Controller, how will they show a list of CR for the user, to that user?
    • 2) open question about consolidate repos for CRs from many data controllers, for the user
  • FOR THE DEMO:
    • Use files to store the CRs
    • Use a filename convention (including extension)
    • Use a dedicated folder to hold the downloaded CR files
    • Use a File Manager to get a list of CRs
  • ACTION: Mark: to ask Joss if the receipt storage application is available (from the COEL work)
• Diagram C: "View a Consent Receipt"
  • 
  • Consentua does not currently do this - who does?
  • digi.me has a viewer in the product today
    • He will have a sample JSON receipt export available this week
    • At this time, digi.me does not want to be a wallet - so no function planned to import general purpose CRs
    • There are too many wallets on the market already
  • OpenConsent is in planning stages of creating a general purpose viewer
    • Current implementation is for 'privacy receipt' which is a subset of a 'consent receipt'
  • Ubisecure
    • Viewer is not planned for this timeframe - they plan to generate CRs for download through the browser
  • Tom Jones has an XSL for diplaying CRs
    • Look here: https://idesg-idp.azurewebsites.net/consentreceipt-min.xsl
    • Ane here: http://tcwiki.azurewebsites.net/index.php?title=Consent_Receipt
• Diagram D: "Move a Consent Receipt"
  • 
  • Open question about how to move the receipt from one system to another
    • Export/download/import (browser)
    • Share action (on mobile)
    • Drag-drop (desktop)
    • Email - do we have a MIME-type for Consent Receipts? (Nope, not yet)
    • Q: What about using an API? A: The diagrams are about user interaction patterns, not infrastructure.

• 3) Timing for initial testing & location of repo

  • ACTION: Andrew to publish the WG's github repo location
  • ACTION: Andrew to create an publish a Google Drive folder for file exchanges (e.g. Exported CR files)
  • digi.me is almost ready to start exporting CRs

From 2018-07-12 call:

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.
• Storyboard
  • 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
• Richard
  • ACTION: to document the technical flows of Consentua in the context of the interop demo sequence
• Sylvester's Action item:

Receipt Reader

 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)

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.
• There are 10 weeks remaining until presentation day!
• Next week's call:
  • Confirm the high-level scenario for the demo
    • Should this be limited to exchange of CRs? or showing data transfer that involves CRs
  • Discuss and finalize a sequence/interaction diagram
    • Confirm the CR-related roles required for the demo (Display-ers/dashboards, the Person, CR Issuers)
  • Richard Gomer is committed to the project (per Chris ) - will have input into the UX issues
    • The Consentua WebSDK demonstrator has embodied some of these concepts
  • Pre-work assignments (due for distribution to the WG by Tuesday):
    • John - will develop a draft sequence diagram