2017-04-20 Meeting Notes (CR)

4 mins

• Roll call

• Agenda bashing

@Former user (Deleted)

1 min

• Organization updates

All

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

• Director's Corner

• Working + Discussion Group Activity

1 min

• Status of Consent Receipt Specification v1

@Former user (Deleted)

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

• 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

30 min

Discuss work backlog priorities for CR v1.1

All

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