Date

2018-12-13

Status of Minutes

Approved

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

Attendees

Voting

Andrew Hughes
Jim Pasquale
Oscar Santolalla
John Wunderlich

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	Former user (Deleted)	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: Director's Corner: 2018: November Work + Discussion Group Activity 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 min	Product roadmap for the demo	All	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 min	Specification update approach	All	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
- 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

Browser not supported