Versions Compared

Old Version 1

changes.mady.by.user Former user (Deleted)

Saved on

compared with

New Version Current

changes.mady.by.user jim pasquale

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

Date

2018-12-1320

Status of Minutes

DRAFTApproved

Approved at: <<Insert link to minutes showing approval>> 2019-12-12 Meeting notes (CR) DRAFT

Attendees

Voting

  • Andrew Hughes
  • Jim Pasquale
  • Oscar SantolallaJohn Wunderlich
  • Mark Lizar
  • Paul Knowles


Non-Voting

  • Robert Mitwicki
  • David Turner
  • Sal D'Agostino
  • Sneha Ved
  • Jan Lindquist
  • 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

AOB

Time

Item

Who

Notes

4 mins
  • Roll call
  • Agenda bashing
Former user (Deleted)
  • Discuss the demo concept paperDiscuss 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 10 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 PanelInformation 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 PCPISCP 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 PCPISCP 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 PCPISCP demonstration, for example: the PCPISCP 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 PCPISCP 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?
  • Decisions needed:
  • The specific set of user stories we want to showcase
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?
  • Support for implementation functions
    • x
  • Structural changes for ease of receipt processing
    • Note that because the v.next receipt specification is net new - so 'breaking changes' probably means that v.next is not backwards-compatible with v1.1
    • x
  • Direct support for interoperable exchange of receipt data
    • Data integrity features, etc
    • Note: this category shares many topics and issues with the Schemas/Overlays work
    • x
  • Recommendations and guidance for specific fields/values
    • x
  • Document family structure for extensions
    • x

See a flowchart version of this here:

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


AOB

Paul - next SSI task is to build a 'consent schema' - 20 attributes so far - will circulate for review

  • Issues about Purpose for data processing are not included at this time - the schema is more about the mechanical aspects of description of the data e.g. aspects of revocation

Mark - liaison work

  • Lots of progress at W3C on vocabulary - GDPR-specific profile/extensions
  • EU government group working on Taxonomy for people and businesses
  • NIST "xpress rules", Healthcare IT, FHIR
  • Should establish a bi-monthly or quarterly liaison information sharing call in 2019



Next meeting

*** Next call 20182019-1201-20 10 10:30 am Eastern Standard Time / 15:30 GMT

NO CALLS December 27 or January 3

 From 2018-12-05 call:

...

  • 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

...

  • 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

...

  • 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'

...

  • 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

...

  • 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.

...

  • From the person's perspective? (excercising data subject rights)
  • From the data controller's perspective?

...

  • 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




...

From earlier calls:

  • Andrew has set up a github repo for next-version specification backlog items, including use cases: 
    https://github.com/KantaraInitiative/consent-receipt-v-next
  • Some possible items for next versions:
    • Structural changes to the spec including a hierarchy of objects that should improve high transaction volume
    • Integration/association of the new Blinding Identity Taxonomy into the CR Spec family (to inform implementers of potential data categories of interest)
    • Recommendations for Customer Journey / UX / UI features
    • Library of industry-specific or case-specific Purpose categories and example Purpose statements
    • Expansion of Consent Types to allow for more than just Explicit Consent situations
    • (idea) Optional receipt metadata to assist privacy dashboards in organizing and processing 'bring forward' items (e.g. "remind me to check this share in 3 months")
    • digi.me product and management have identified six areas for development
      • consent over period of time (rather than instantaneous consent)
      • termination/modification of consent from either side
      • high transaction volume & low per-instance cost
      • how the 'receipt' fits into accounting systems infrastructures
      • receipt as the basis for legal matters and actions
      • UX/UI concerns
    • for Clinical Trials uses, data holder is required to keep data for 10 years - need to consider longevity of the receipts to go alongside data holdings