...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Date
2017-04-20
Status of Minutes
DRAFTApproved
Approved at: <<Insert link to minutes showing approval>> 2019-12-12 Meeting notes (CR) DRAFT
Attendees
Voting
- Andrew Hughes
- Harri Honko
- Jim Pasquale
- Iain Henderson
- Mark Lizar
- John Wunderlich
...
Non-Voting
- David Turner
- Jens Kremer
- Samuli Samuli Tuoriniemi
- Robert Lapes
- Sal D'Agostino
Info |
---|
|
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
...
|
|
1 min | | All | 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
|
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)](/wiki/s/1238699948/6452/c4fd8688f220479d537f6a0bca23e41d59d1be40/_/images/icons/emoticons/smile.png)
- 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
|
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
|
|
...