Versions Compared

Key

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

Date

2018-1112-2906

Status of Minutes

DRAFT

Approved at: <<Insert link to minutes showing approval>>

Attendees

Voting


Non-Voting

  • Jan Lindquist
  • David Turner
  • Paul KnowlesSneha Ved
  • Sal D'Agostino
  • Sneha Ved
  • Peter Davis
  • Mary Hodder

Regrets

  • Iain Henderson



Quorum Status


Meeting was <<<>>> quorate

...

Continuation of the product roadmap discussion...

From the 2018-11-29 call:

  • Andrew walked through the mindmap of choices
    • After thinking about it and discussing, we will have to do things related to Use cases, Spec updates and 'recommended lists' in coordination with each other
    • WG will think about work areas that are critical to support their product directions/plans
    • It is essential that individuals take on leadership of work that they have a direct stake in successful completion
  • We discussed use of a simple use case format and approach. Andrew pointed to the pages at the DG for ID Proofing Use Cases: Use Case style and instructions

From the 2018-11-22 call:

Let's look at a few appraoches to deciding on what happens next:

  • Specification structure changes & fixes
    • For example: adding 'object hierarchy' (digi.me), any field data types that turned out to be incorrect, other feedback from implementers
    • For example: adding capability for 'system-added' additional data to preserve custom data from specific implementations
    • For example: changes needed for signing, encryption, key management, Decentralized Identifiers, Verfiable Credentials,
  • Specification 'data dictionary', 'pick lists', 'recommended lists' (is this the 'Lexicon' item?)
    • For example: Purpose categories, purpose lists, data categories, taxonomies (Blinding Identity Taxonomy) & ontologies
    • For example: Integration/association of the new Blinding Identity Taxonomy into the CR Spec family (to inform implementers of potential data categories of interest)
  • Full exploration of one or two use cases - to inform/supply specification changes and additions above
    • This should include building prototype, demo or actual software that uses the updated specification material
      • For example: think about extra stuff that a well-functioning 'privacy dashboard' would need.
      • For example: using the 'receipt' concept for record-keeping the full 'Agreement'
      • For example: using the 'receipt' for any/all legal basis for processing, not just 'consent'
      • For example: pick any actor in the system and build out all the stuff they require in the overall system (what would an external record-keeper-provider need to have?)
      • For example: analysis and enhancement for use of Receipts in court/evidence
  • Direct sharing and concept integration between CIS WG and other consortia WGs
    • For example: Hyperledger Indy Semantics WG (was Sovrin foundation Schemas & Overlays WG)
    • For example: W3C community groups (Credentials CG, Decentralized Identifiers CG, Data Privacy Vocabulary CG)
    • For example: IEEE P7102 Machine readable privacy terms; IEEE P7002 Data privacy process (privacy engineering)
    • For example: ISO 29184 Privacy Notices and Consent; ISO P317 Privacy by design (consumer products)
  • 'Protocols' specifications
    • A three party consent-data-exchange - a protocol definition/specification
      • What about an API definition?
      • What about 'Negotiation' interaction models, protocols, etc
  • Other ideas
    • Application of the Consent Receipt in IAB "Consent Management Solution" infrastructures
    • Integration of 'Consent Receipt' into Hyperledger software proposals (See HIPE - Consent Receipts for Hyperledger Indy)
    • Recommendations for User Experience / Customer journey
    • Schema Overlays for data presentation transformations (like localization/language translation)

Comments/Discussion:

  • There needs to be a common design paradigm for data sharing of/for/about an individual - so that systems implementers, designers etc can work together. For example: jlinc.com
  • Data/information management guidance - how does the receipt align to the actual data it came from?

Prep material for 2018-11-15 call:

A new flow chart showing a generic 'agreement-oriented' viewpoint:

https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J0PS

Andrew's email to prepare for this call:

https://kantarainitiative.org/pipermail/wg-infosharing/2018-November/003156.html

These are some of the questions that came to my mind, to ask at the flow chart steps:
* At each point in timeline what data is offered or consumed?
* What information and metadata should persist? (to record keeping)
* Under different legal bases what information should be provided to the individual?
* What happens at first use? Does something different happen at subsequent use?
* What information is needed to exercising a data subject right? (and is that information recorded anywhere?)

From 2018-11-15 call:

  • Sneha notes that their flow is more party-party-consent manager - so the high level 'agreement' flow chart needs adjustment
    • Andrew: Yes. The generic flow chart is intended as a starting point - more specific ones will be developed for different use cases
  • Andrew walked through the flow chart
  • Q: is the idea of a third party record keeper archivist in play?
    • A: yes - not at this level of detail - because this flow chart does not show who is performing the action, just who is responsible for the action
  • Discussion ensued
    • Analysis of any particular use case using the flow chart as a tool
      • The details of what records should be kept are specific to the use case being analysed
    • We will build out a taxonomy of use cases that we analyse
  • General sense of the room is that this is a good base model from which we can derive specialized flow charts to suit any use case

From 2018-11-08 call:

Some food for discussion:

  • If we believe that the CR should be adjusted to enable general use for any legal basis for processing, what steps are needed (where are the requirements? what are mandatory/optional features? etc)
    • Transformation of the specification into a "Notice Receipt"
  • If we believe that 'consent' will become an peer with the other legal bases for processing, then maybe we should leapfrog and look at requirements from ePrivacy Regulation, and take an affirmative position in the marketplace that Kantara Consent Receipts are designed to be fit-for-purpose to address ePrivacy, GDPR and GDPR-similar regulations.
    • Document use cases from specific companies - to give us focus
  • Realign thinking towards "Consent Sharing & Information Sharing"
  • Is there support in this WG to use the "Contract Law" concepts as the scaffolding/framework for future development of the "Kantara receipt" construct?
    The use cases described last week (in addition to the ones in the github repo) were:
    • Privacy Dashboard
    • Evidence of Action
    • Agreement Details and Transaction Records
    • Standardized Message Data Structure
  • Comments
    • Having the concept of "contract" would be helpful
    • GDPR pushes to get away from "data as currency" - the purpose for the interaction is paramount and should be the justification for the 'consideration'
    • Be very cautious that applying the Contract Law metaphor could overly influence our thinking about how we design and apply consent
  • Address the taxonomy of privacy, notice, control

From 2018-11-01 call:

Andrew led the group through a discussion looking at the central 'agreement' between data subject and data controller in light of basic concepts of Contract Law in the Common Law to see what patterns and insights are available

Andrew has uploaded some material to help the discussion: Product Roadmap Ideas

Blog: Kantara Initiative Work Groups on Data Sharing and Consent

Mind map to go with the blog

Kantara consent high level use cases.pdf

From 2018-10-04 call:

  • If the legitimate basis is not 'explicit consent' - but rather legitimate interest, is the concept of 'data receipt' still viable?
  • Mark - yes, the current CR was designed to be not confined to 'explicit consent' - so yes, the receipt concept will work for other bases for processing
    • in particular - for updates to privacy notices
  • Mark Q: would it be interesting to have additional values for the 'consent type' field? A: YES! 
    • Jim: maybe this should go to the Consent Management WG?
  • A lawyer at the Seattle event pointed out that it would be useful to capture the actual privacy notice that was agreed by the user.
    • OpenConsent has an alpha product that might suit the purpose
    • There is a systemic problem that needs to be addressed - and capturing the privacy notice won't actually help
    • If there is a strong need for a high value receipt, then it would be very useful to capture the actual notice text
    • So maybe the receipt could have optionality to allow for capture of the notice text.
  • WG needs to take some time to discuss the UX - schedule it
    • Tom has posted some examples that could be discussed
    • Mark - OpenBanking has posted UX guidance
  • Schedule specific multiple calls for this to discuss what the user should see, and how this translates into the 'receipt' concept
    • Should this WG do a spec or guidance on UX or UI?
    • Should this WG talk about what the 'receipt' means and / or represents?
    • (YES to both question)
  • Andrew: suggests first design call on Thursday October 18, 2019 and then every 4 weeks to be kind to the down-under-ers.

Iain: the highest value work item is the lexicon work

Time

Item

Who

Notes

4 mins
  • Roll call
  • Agenda bashing
  • discuss the road map - are there high priority items?
  • discuss ideas for EIC May 2019 demo and other talksDiscuss what we should demo at EIC



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
45 minRoadmap ideas for Kantara CIS WG productsAll
10 minAdding feature requests to next version of spec familyAll
  • 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
5 minProduct roadmap for the demoAll
  • Target is EIC May 2019
AOB

"Robert and I will be attending Hyperledge Global Forum in Basel from December 12th to 15th. We will be implementing all of the remaining Overlay types on top of a "Demographics" schema. We will work with Jan who will be adding his Consent Receipt piece into that piece. This will get us to the next stage of the Overlaid Schema demo. The great thing about the demo at that stage is that it'll be utilising the Blinding Identity Taxonomy, Schema Overlays and Consent Receipt. It should give us a solid start in all of this. Thoughts?"

These are the different Overlays that we are working on and will be implemented in that demo. We have 9 overlays defined so far.

Entry Overlay 
• Label Overlay 
• Information Overlay 
• Subset Overlay 
• Sensitive Overlay 
• Encoding Overlay 
• Format Overlay 
• Conditional Overlay 
• Consent Overlay

Product roadmap for the demoAll
  • Target is EIC May 2019
  • 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

AOB



Next meeting

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



...