2017-04-20 Meeting Notes (CR)

• Roll call
• Agenda bashing

• Organization updates

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

• Director's Corner
• Working + Discussion Group Activity

• Status of Consent Receipt Specification v1

• All Member Ballot is now open - closes on Monday, April 24, 2017
  • Reminders going out now 

• Discuss myData team comments

Note from prior meeting: myData EU-based lawyer commented that the CR v1.0 draft has elements that are based on UK/US Common Law, rather than civil codes (GDPR)

• myData team submitted commented v1.0 spec - attached to Consent Receipt v1.1 Work Backlog page

2017-04-20 notes:

• Jens Kremer - has provided review comments on the v1.0 with respect to GDPR fit
  • Had done a related PhD recently
  • A review from an independent viewpoint - with no particular prior knowledge of the Kantara context
  • Consider this as an external perspective - from the possible viewpoint
• Main issue might be that a dichotomy is starting to emerge between common law systems versus public law systems (state regulation, rights-based)
  • The CR work takes an individual centred /common law perspective - and also an Organizational perspective
    • This will look strange to an EU lawyer
    • Fundamental difference: 
      • Common law approach - the consent is not regulated - e.g. give the people the information and the people can agree on anything
      • Public law approach - this is regulated and not up to the participants to decide - there are absolutes - the person cannot agree to arbitrary conditions
        • This is grounded in the idea that privacy and data protection is a fundamental right - this is in contrast to taking a contract approach
  • It might be possible to create a specific profile that is constrained to the GDPR rules
    • This might be a case of reconsidering how the definitions are stated to ensure that they fit with the GDPR terminology (CR v1.0 uses ISO definitions)
• Mark: the CR v1.0 is intended to be a minimum-viable specification that is intended to be extended
  • ISTPA Document: http://xml.coverpages.org/ISTPA-AnalysisOfPrivacyPrinciplesV2.pdf
  • There should be a work item to address terminology additions to match the local regulatory language
• David
  • Jens has described things related to the consent process, and the CR is a record of that process
    • The consent process precedes the CR itself and is independent of the receipt itself
  • This is the same difficult topic the WG has worked through before
    • It is problematic to define the receipt format and then require all processes to output that format
• Robert
  • The use of the word "Consent" might be problematic - it is an overloaded term
  • The GDPR is simply one regulatory approach amongst many
  • e.g. 'consent' in the (non-regulated) USA is associated with 'choice' whereas 'choice' and 'consent' are very different things in EU/UK
• Andrew
  • Are there a set of requirements that can be stated for consent-related process?
• Jens
  • The way this specification is written, the concepts of consent and the recording of consents are not split out cleanly
  • It would be more helpful to separate the concepts into a 'universal' or 'generalized' document. And the specification of the receipt itself can be freed from the specific regulation.
• Mark - add to the backlog
  • Extend the MVCR to include the GDPR requirements
  • Review the CR text to ensure that it is unbiased to any particular regulation
• John
  • The spec definitions should be more universal & if the use of the ISO definitions are problematic then we need to fix it
  • GDPR is important; China has just passed privacy regulations; India is going to address Aadahaar issues soon
• ACTION: compare ISO 29184 (notice requirements) to GDPR definitions to identify discrepancies in concepts and definitions
• John: note that the GDPR choices for consent and notice SHOULD BE a subset of what's on offer in the CR - if not then there's a problem
• Andrew: is development of a generalized/universal set of mandatory requirements for any controller contemplating 'consent-related' processes - this is what will be needed to develop conformity assessment criteria that assessors can then use (Yes)
  • Harri notes that the requirements are coming out from ICOs and national DPOs - this will be a good source for Kantara's work (Andrew) - a discussion will be needed regardless
• Harri: WG must figure out how to do different profiles in a technical sense
• Mark: remember that where the User holds their own data, things must be worked out

Consent Receipt v1.1 Work Backlog

• Discussed items 1-11 on the CR v1.1 backlog list

• Mary
  • The caution about "Purposes lists" and "Sensitive data types" needs to be resolved - must be very cautious about how these are displayed to the user, especially if it's sensitive data - need to create recommendations
• Mark
  • Need to set up a backlog - and define a work plan and schedule
  • Set a date for CR v1.1
  • Need to write guidance on spec usage
• Need consensus on
  • Prioritization of backlog
  • Need to consider any issues that are used for GDPR implementation
  • The original agreement was to do 6-month epics