Page Comparison

• Roll call
• Agenda bashing

• Recap of MyData conference
• Andrew has set up a github repo for next-version specification backlog items: https://github.com/KantaraInitiative/consent-receipt-v-nextMark: has posted information on consent types to the list - these are needed to make progress on other topics

• Organization updates

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

• No new demo partners will be ready for Amsterdam - too short notice
• Retargeting to EIC in May
• digi.me is scheduling product updates now
  • has suggestions for CR structural updates - we need to figure out how to introduce these, since they would be 'breaking' changes for everyone else
  • Julian Ranger has recommitted to getting the CR better integrated into the product - for example, to be able to get receipts inbound into their dashboard concept
  • More info in a few weeks

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

Continuation of the discussion about 'what should interoperate?'

not discussed

Permissions v User Consent discussion

notes from From 2018-09-13 call

From 2018-09-27 call:

Proposal:

Permission = Authorization to act

Data Permissions = the functional actions that are allowed on information (database: Create, Read, Update, Delete; communications: Copy, Transmit, Store; data flow: Collect, Use, Disclose) or resources.

User Consent = Voluntary agreement by the person to take an action. GDPR includes 'unambiguous'

• So, a system might be authorized to act on personal data with or without a user's agreement. A person may grant permission or authorize a system to act on personal data.

Questions:

• Is an OAuth 'consent' / 'authorization' / 'permission' dialog box truly 'user consent'?
  • If it is not 'user consent' then why not?
  • So: the process of obtaining agreement from the user in the OAuth dialog box is "User Consent". What the user has agreed that you can do with their resources is "authorization" in the sense that they give you 'permission' to take actions.
• How does this apply to Collection, Use and Disclosure of information? (these are the data flow words)
• To tease out the usable definition of 'authorization': What is the difference between Authorization and Access Control? (data & systems-context)
  • Authorization is the granted right to proceed (a.k.a 'permission')
  • Access control is the functional actions that are allowed

Alternative proposal:

• Permission is a general authorization to act. Authorization may be granted by actors that are not the data subject.
• Consent is a specific agreement to act in a limited case.

Note:

• Permission / authorization as a verb can be granted through an act of user consent.

Another proposal:

• Should the terms should be Authorization and User consent

• Andrew has set up a github repo for next-version specification backlog items, including use cases:
  https://github.com/KantaraInitiative/consent-receipt-v-next

2018-10-11 18 Same time same number