2018-12-13 Meeting notes (CR)

Date

2018-12-13

Status of Minutes

Approved

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

Attendees

Voting


Non-Voting

  • David Turner
  • Sal D'Agostino
  • Sneha Ved
  • Colin Wallis

Regrets

  • Paul Knowles
  • Mark Lizar


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

4 mins
  • Roll call
  • Agenda bashing
  • Discuss the demo concept paper
  • Discuss approach to specification updates



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 Andrew of your implementation.

  • TIIME, Vienna, February
  • EIC, Munich, May
  • Identiverse, Washington, June
30 minProduct roadmap for the demoAll
  • Target is EIC May 2019
  • Iain: suggests the 'virtual product' name should be "Kantara Initiative Information Sharing Control Panel"
  • Peter: Is it a requirement that the CR is a standalone document or can it be embedded in a parent document? (may need to update the JSON Schema to specify)
  • Peter: What does 'change permissions' mean? A: Intended to convey that the Subject might instruct the Controller to restrict processing in some way.

Proposed description

The following is a very early draft description of the system we will demonstrate at EIC 2019 and other events.


The main purposes of the Kantara Initiative Privacy Control Panel (Kantara PCP) Information Sharing Control Panel (ISCP) demo system are a) to allow people to see, organize, find details via a ‘data processing receipt’ construct about the conditions under which they agreed to provide information for data processing; and b) to give them tools to investigate the data processing receipts they might have received or modify the permissions they granted when they initially shared the data for processing.

In the Kantara vision, whenever an individual is asked for their personal data, or whenever their personal data is acquired, a ‘data processing receipt’ is created by the data controller. The receipt includes details about the conditions under which the data was obtained: the privacy notices provided;  the lawful basis and purposes for collecting and processing data; the terms of the agreement and other metadata related to the interaction.

These data processing receipts could be offered by the data controller’s system to the individual for storage in their personal Privacy Control Panel Information Sharing Control Panel application. 

Once the data processing receipts are in the personal PCP ISCP, the person can organize them and inspect them to ensure they are valid, current and actually represent what happened. 

The PCP ISCP gives the person tools to take action with the receipts including view, validity check, request the data, revoke consent, change permissions, or erase the data. In other words to exercise their data subject rights.

On the consent management platform and data controller system side, standard data processing receipt APIs could be offered. The PCP ISCP utilizes these APIs. 


The Kantara Members in the Consent & Information Sharing WG can participate in the demo by showing their product features that provide the different functions needed for the PCP ISCP demonstration, for example: the PCP ISCP dashboard, the data controller functionality to generate receipts, API platform provider, the ‘app’ used by the person, receipt viewer, receipt language translator, and so on.


The concept is that the products could, with very minor enhancements, be a component of the overall Kantara PCP ISCP system. We will showcase a future vision of the data processing ecosystem where the individual has more insight and control over their data.


Decisions needed:

  • The specific set of user stories we want to showcase
  • Should we change the name to Information Sharing Control Panel?
    • Comments on the call that "Privacy" is more consumable to the wider world than "Information Sharing" - must consider the audience
30 minSpecification update approachAll
  • Discovery approach leading to backlog leading to prioritization?
  • How do we decide what changes we must do in this round versus deferrable changes?

AOB



Next meeting

*** Next call 2018-12-20 10:30 am Eastern Standard Time / 15:30 GMT

NO CALLS December 27 or January 3







 From 2018-12-05 call:

  • digi.me is considering doing the import/export functionality for January
    • suggests showing of functionality of the 'privacy dashboard' concept
    • suggests showing a communication flow between person, controller and a processor - showing how changes to preferences are communicated
    • will show demo to Jim of consent receipt spec new features of digi.me - these probably will go in the next release
  • Sphere Identity
    • 3-party consent will be implemented and tested in January
    • will have an end-end demo at EIC
    • showing how data sharing and consent management works (data subject, data controller, Sphere)
    • would need to add an 'export' function
  • Consentua
    • Focus on the interoperability aspect
    • 1) How do i combine multiple receipts into a single file? (zip, JSON format, etc) - to demo parsing packets of receipts - portability between dashboards
    • 2) How to make a CR actionable - how to check it, revoke it, mutate it, is it valid in the service that issued it - this would allow dashboards to become 'control panels'
  • Airside
    • Could use emulators to show mobile. Could also run and pause a video.
    • Wants to speak about how CRs are used in their general aviation app - there are iPad/Android version
    • Their data organization is information oriented, not privacy-first oriented
    • The 'dashboard' feature for General Aviation might be the Passengers sharing their passport data to the Pilot for flight manifest compliance
  • OpenConsent
    • Power is in the 'proof' aspect of this - proof about what Notice was given
      • For consent, Notice is required, followed by an Agreement
      • Consentua has the concept of 'provenance' - all the elements that went into the agreement.
      • Andrew suggested using the word 'agreement' instead of 'consent' - nobody agreed (smile)
    • This is 'consent by design' that demonstrates the increased quality of consent.
    • Idea: if there was a bare 'notice receipt' (a subset of the explicit consent receipt) that could be powerful to keep track of where notice was or was not provided correctly.
  • What point of view should we demo?
    • From the person's perspective? (excercising data subject rights)
    • From the data controller's perspective?
  • Demo of a Privacy Control Panel?
    • One interface showing where the person shared their information for processing
    • The person can interact and change their preferences related to these information processing interactions
    • The control panel operates on a more complete capture of the provenance of the consent interaction
  • Consensus reached - this sounds like the right concept for the demo - now we need to work on the details