Skip to end of metadata
Go to start of metadata



Status of Minutes


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



  • Andrew Hughes
  • Harri Honko
  • Jim Pasquale
  • Iain Henderson
  • Mark Lizar
  • John Wunderlich


  • David Turner
  • Jens Kremer
  • Samuli Tuoriniemi
  • Robert Lapes
  • Sal D'Agostino

Quorum Status

Meeting was quorate

Voting participants

Participant Roster (2016) - Quorum is 4 of 7 as of 2016-10-06

Iain Henderson, Mary Hodder, Harri Honko, MarkLizar, Jim Pasquale, John Wunderlich, Andrew Hughes

Discussion Items

4 mins
  • Roll call
  • Agenda bashing

1 min
  • Organization updates

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

1 min
  • Status of Consent Receipt Specification v1
  • All Member Ballot is now open - closes on Monday, April 24, 2017
    • Reminders going out now 
15 min
  • Discuss myData team comments
Harri Honko

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)

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
  • 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 (smile)
  • 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
30 minDiscuss work backlog priorities for CR v1.1All

Consent Receipt v1.1 Work Backlog

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

Parked notes about v1.1 approach from previous meetings:

  • 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