2019-01-31 Meeting notes (CR)

2019-01-31 Meeting notes (CR)

Date

2019-01-31

Status of Minutes

Approved

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

Attendees

Voting

 

Non-Voting

  • Jan Lindquist

  • Sal D'Agostino

  • Sneha Ved

  • Peter Davis

Regrets

 

  • David Turner

 

Quorum Status


Meeting was <<<>>> quorate

 

Voting participants

 

Participant Roster (2016) - Quorum is 6 of 11 as of 2018-11-19

Iain Henderson, Mary Hodder, Harri Honko, Mark Lizar, Jim Pasquale (C), John Wunderlich (VC), Andrew Hughes (VC), Oscar Santolalla, Richard Gomer, Paul Knowles, Samantha Zirkin

Discussion Items

Time

Item

Who

Notes

Time

Item

Who

Notes

4 mins

  • Roll call

  • Agenda bashing

@Former user (Deleted)

  • EIC and Identiverse speaker proposals status

  • Status: Wiki refresh work

  • Status: Distribution-version of slide deck describing the work here (consent receipt today → personal data processing receipt tomorrow - or whatever we decide)

  • Discuss EIC demo and scheduling

 

 

5 min

  • Organization updates

All

Please review these blogs offline for current status on Kantara and all the DG/WG:

There is a wiki page that will hold all the known implementations of Consent Receipts - Please update the page or inform Jim, or John, or Andrew of your implementation.

  • TIIME, Vienna, February

  • EIC, Munich, May

  • Identiverse, Washington, June

40 min

Product roadmap for the demo

All

  • Target is EIC May 2019

Here's the project page for the "Demo v2"

Andrew's personal opinion on what to highlight:

  • The fact that giving the person tools necessary for them to keep records (the 'receipts') about their data controller & personal data processing interactions is a new thing in the world

  • The ability for the person to take action because they have these records in their possession - the Privacy Control Panel

  • The fact that interoperability standards allow many products to work in an 'ecosystem' way

  • Even if the audience does not believe that the lawful basis of consent will become a mainstream thing, the person-side record keeping idea is a good one that has broad applicability

Comments:

  • This opens the door to ongoing management of the relationship by the person with the data controller/other

  • The consent receipt is also a Notice

  • People have an independent record of the interaction in the receipt

  • Have hard receipts gone away because they are viewed as 'too much friction'? Is this dangerous?

 

Decisions needed:

  • The specific set of user stories we want to showcase - what is the "Consent Journey" of the person?

  • The roles that each product will cover in the demo

From the project page, the product roles were stated as:

Role

Functionality

Product

PCP Dashboard

Dashboard - view and organize receipt from multiple sources



Control Panel Function

The part where a person clicks on a button that causes the Receipt Management Platform to take action

digi.me

Receipt management platform

Communication substrate - e.g. one possible function: when user clicks on button to exercise a data subject right, this calls the platform which sends instructions to the data controller to take action

digi.me

Receipt generator (API?)

Might be part of the receipt management platform?

digi.me?

Data controller application

in Demo v1 it was the Bookstore app



Data controller registration



Maybe OpenConsent?

digi.me

Receipt Viewer app





Receipt language translator

Display the receipt in a different language e.g. French



Receipt storage facility

"wallet" concept; Downloads folder; browser storage; etc

digi.me (consent manager)

Comments:

  • The discrete functions need to be identified

  • Receipt issuers should be enrolled in advance (data controller should be known)

  • Can we show multiple wallets that hold receipts?

  • Should build on the flow of the Demo v1 - person does stuff, gets receipts, sees them, acts on them

  • Is the 'wallet' (a.k.a. the receipt storage location) singular or multiple?

    • Sphere app can display receipts from their own storage locations

    • Digi.me only shows receipts within their system

      • Jim is pushing engineering towards the idea that the 'control panel' should be able to work on receipts in other app storage locations

  • Passing control over a receipt (to act on a receipt and manage it going forward) to a 3rd party breaks the security concept of digi.me and Sphere's apps

    • Exporting a receipt is possible, but action on the exported receipt might require a redirect back into the Sphere app

    • This is probably the same with all app ecosystems

  • Jan - looking at the topic of using the receipt as a data schema but also using the universal namespace/identifiers (a.k.a. Decentralized Identifiers) to reference the entities and object might allow for broader interoperability

  • Peter: we lack the protocols for operations on the receipts themselves - maybe do this in Kantara

  • Jan - last week call - Paul and Jan presented on the Hyperledger Indy work for interop

  • Remember that we are limited by what exists today - a list of JSON files

    • The 'take action' function might be a simple "open URL in the receipt issuer's app"

  • Action: Andrew to draw an information flow diagram for discussion for the demo

  • Action: ALL - to think about the functionality that your products can do today in light of the "Privacy Control Panel" idea - we will try to do a heat map to try to sort out role assignments and find gaps

 

Deferred

Specification update approach

 

See a flowchart version of this here:

https://share.mindmanager.com/#publish/b-DWOcuKGnVY1PXBKXTpL0-DQOeqmZMGfGUAPiC5

 

AOB

 

Mark: Health Use case proposal

 

 

Next meeting

 

*** Next call 2019-02-07 10:30 am Eastern Standard Time / 15:30 GMT

https://global.gotomeeting.com/join/323930725