Date

2018-10-11

Status of Minutes

Approved

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

Attendees

Voting

Andrew Hughes
Jim Pasquale
Richard Gomer
Mary Hodder
Mark Lizar

Non-Voting

Tom Jones
David Turner
Colin Wallis
Sal D'Agostino
Sneha Ved

Regrets

Oscar Santoalla

Quorum Status

Meeting was <<<>>> quorate

Voting participants

Participant Roster (2016) - Quorum is 5 of 9 as of 2018-07-12

Iain Henderson, Mary Hodder, Harri Honko, Mark Lizar, Jim Pasquale, John Wunderlich, Andrew Hughes, Oscar Santolalla, Richard Gomer

Discussion Items

Time	Item	Who	Notes
4 mins	Roll call Agenda bashing	Former user (Deleted)	Mark: has posted information on consent types to the list - these are needed to make progress on other topics
5 min	Organization updates	All	Please review these blogs offline for current status on Kantara and all the DG/WG: Director's Corner: 2018: September Work + Discussion Group Activity There is a new wiki page that will hold all the known implementations of Consent Receipts - Please update the page or inform Andrew of your implementation. Planning a Member Plenary meeting October 26-ish San Francisco (Friday after IIW) Are there specific cross-group items you'd like to propose to work on? Please register here
5 min	Demo updates / product roadmap	All	No new demo partners will be ready for Amsterdam - too short notice Retargeting to EIC in May
15 min	Discuss approach to creating usability guidelines	All	Consent Receipt Usability and Accessibility Project Comments Accessibility is a small part of the usability domain Usability and accessibility is a narrow part of design - tends to be about technical design (button size etc) We should be looking at Interaction Design for the consent receipt Start with minimal guidelines for developers - there are accessibility checkers that can be run against sites to give hints for improvement User experience: Aesthetics, good experience, create desire to interact further. Usability: Does something functionally meet my needs? What are we trying to design? What is the artifact that we want? How to design to enable "Informed" consent? And how to maintain the 'state' of that consent so that when the user returns they can comprehend the state of play. "Consent State": the essential of the consent receipt "Privacy Signals": to figure out state changes Example from Tom: https://tcwiki.azurewebsites.net/index.php?title=Consent_Receipt_Construction Does the "Purpose for processing personal data" statement meet the requirement that it must be understood by the user? Approach?: Provide developers a list of the regulatory requirements and guidance on how they can meet those requirements in their technical designs Look at ISO 29184 drafts for some usability material Mary will post material from the IDESG User Experience committee - guidance on what points to consider user experience and how to evaluate Goals what are we trying to design? What problem are we trying to solve and for whom? For people/users: they do not understand the language used in e.g. the Privacy Notice, Privacy statement, Purpose and Consent, etc - and therefore are unable to make informed choices about processing of their personal data. For designers/developers: Developers do not understand or know of the requirements imposed on their products from applicable regulations. And they don't know how to design in ways to meet those requirements in ways that satisfy item 1). For people/users: People are blocked from getting their stuff done by the privacy notices, consents and other disruptions. They want to be interrupted when it matters to them, otherwise not. (Note that this WG does not have the expertise to solve this on the broad scale) Objectives/Outputs? Semantic analysis about what the person should understand - to inform designs Design guidance on how to express "privacy state" or "consent state" Design guidance on how to indicate "state changes" or "privacy signals" What should the WG produce next? A report about "what is problematic" Consent types Purpose definitions for informed consent The WG discussion was inconclusive, so we decided to start an outline of a document: Tom and Mary to draft an outline of what the issues/topics are that need to be addressed by this WG - by end of Tuesday Mary to also contribute document drafts for taxonomy
20 min	Interoperable Consent Receipt roadmap ideas	All	Continuation of the discussion about 'what should interoperate?' `not discussed`
0 min	Interoperable Consent Receipt roadmap ideas	All	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
5 min	Adding feature requests to next version of spec family	All	Andrew has set up a github repo for next-version specification backlog items, including use cases: https://github.com/KantaraInitiative/consent-receipt-v-next
	AOB
	Next meeting		2018-10-18 Same time same number

Browser not supported