WG Project Areas

This page lists WG projects.

A project is described by the PMI as: "A project is a specific set of operations designed to accomplish a singular goal."

A Kantara Initiative Discussion Group or Working Group Project is a specific set of activities designed to create and publish a document described in the Group's Charter.

The characteristics of a Kantara Group Project are:

  • The group project must result in a Draft Technical Specification or a Draft Recommendation or a Draft Report as defined in the Kantara Operating Procedures
    • Note: the Drafts are intended to be approved by a procedure listed in the Kantara Operating Procedures
  • The group project must be temporary with an agreed-upon target end date
  • Contributors to the group project must have agreed to the group intellectual property policy via the Group Participation Agreement procedures
  • Group project contributors may include volunteer or paid/contracted participants
  • Material related to a group project must be stored on Kantara-approved storage locations. For example, the Kantara wiki or Kantara projects area on github.
  • A group project outline must be approved by the group and listed in the appropriate group project list pages prior to commencement of work

 The generic term for a "Kantara Initiative Discussion Group or Working Group Project" is a "Kantara Group Project".

Project NameProject DescriptionOutput typeLeaderPublication titlePublication SynopsisProject-Publication Status
CISWG Research: Consent in the WildResearch into the terms used for authorisations spanning permissions, agreements and consentresearch summary for best practiceMark LizarTerms Conformance Research 

Receipt Demo v2Design and planning for the next interop demo: the "Kantara Initiative Privacy Control Panel"Demonstration at eventsAndrew Hughesn/aTBDActive
Data Receipt Specification v1.1bis Development Project
  • Collect use cases related to 'personal data collection and processing' scenarios.
  • Derive functional and non-function requirements from use cases that should be considered for coverage in the next version of the receipt specification (v1.1bis). 
  • Prioritize requirements for inclusion in v1.1bis
  • Produce Draft v0 of v1.1bis
  • Discuss and refine v1.1bis drafts in the CIS WG
  • Ratify WG Technical Specification as v1.1bis for public comment period
  • Complete the procedures towards ratification and publication of specification v2.0

The backlog of proposed changes to specification and specification family:

Github Project: https://github.com/KantaraInitiative/consent-receipt-v-next/projects/2

Github Issues list: https://github.com/KantaraInitiative/consent-receipt-v-next/issues

Updated specifications or new publicationsTBCTBDTBDActive
Consent Receipt Usability and Accessibility Project

Work project to determine approaches to specifying usabiity and accessibility recommendations for implementation of consent receipts, and development of those specifications. Includes topics like user experience, user interface, web content usability, accessibility standards.

Report leading towards Recommendation

"Report on consent receipt usability and accessibility requirements"
MyData 2018 Consent Receipt Interop Demo

The goal is to demonstrate either live or recorded instances of exchanging consent receipts between organizations. The intent is to show that data is flowing and that consent receipts are being parsed correctly.

The Consent Receipt Interop Demo will be at the MyData 2018 conference in Helsinki, 27-31 August 2018

Interop Demo

Jim Pasquale

Andrew Hughes

John Wunderlich

Consent Receipt SpecificationA consent receipt is a record of a consent provided to an individual at the point in a person agrees to the sharing of personal information.  It's purpose is to capture the privacy policy and its purpose for sharing personal information so it can be  easily used by people to communicate and manage consent and sharing of personal information once it is provided. Draft Technical SpecificationDavid Turner"Consent Receipt Specification"Consent Receipt SpecificationCOMPLETE
User Submitted TermsThe User Submitted Terms project will create a common set of icons that customers can use to signal their intent. This project is meant to build a Minimum Viable set of term icons, their definitions and example engineering code for submitting terms and answering them. The purpose of USTs are to allow individuals to request their preferred treatment of their data, before submission. This is meant is to change the dynamic between entities that most often ask their users to accept terms from the entity with no negotiation. USTs would bring a negotiation aspect to the consent process, before a Consent Receipt is created. UST development will include participants from all relevant domains including UX and usability, engineering, legal, product, marketing and standardization, as well as other parties wishing to join and assist the group. UST development should result in a standard adopted by the Kantara Initiate and eventually through a formal standard's body.
Mary Hodder

User Submitted Terms project overview

UST Project Scope

Active - Development
Enabling Maximum Data Portability through GDPR

A brief and simple description of the project objective, rationale for creating the publication, specific entities that will use the publication and related work inside or outside of Kantara.

The General Data Protection Regulation (GDPR) introduces a new right of Data Portability for individuals (data subjects). The text states that ‘the data subject shall have the right, where personal data are processed by electronic means and in a structured and commonly used format, to obtain from the controller a copy of data undergoing processing in an electronic and structured format which is commonly used and allows for further use by the data subject’.

The text goes on to say: 'Where the data subject has provided the personal data and the processing is based on consent or on a contract, the data subject shall have the right to transmit those personal data and any other information provided by the data subject and retained by an automated processing system, into another one, in an electronic format which is commonly used, without hindrance from the controller from whom the personal data are withdrawn.'

The Data Portability section concludes with: ‘The Commission may specify the electronic format referred to in paragraph 1 and the technical standards, modalities and procedures for the transmission of personal data pursuant to paragraph 2. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 87(2).'

On first reading, one might assume that the above is relatively straightforward to deliver in the technical sense; a range of technical routes to doing so have been around for a long time. However, data portability is seen as a threat to many existing organisations. Free-ing up the data they have carefully gathered on customers is seen far more as a threat than an opportunity; that is multiplied considerably when viewed through the lens of data being ported to a competitor.

The above is why customers/ users do not have data portability as the norm at present. There have been attempts to deliver it, all have stalled or being minimised to the point of being meaningless. Those with the data roll out numerous excuses and reasons to water down the art of the possible; reasons for not delivering on the premise include:

• ‘How can we be sure we are providing the data to the right person/ organisation?
• We’re not sure we can share this data, it might get lost/ hacked
• Some of the data is ours, the customer should not be able to leverage that for free

What has emerged from previous attempts has been limited lists of standardised data listing, and data sharing formats such as ‘download a .csv file’. The task taken on by this project within CISWG is to take the alternate perspective. Rather than minimise, slow down and put barriers in front of data portability, we will focus on fast tracking, and setting the bar based on what modern technologies. In practical terms that means:

• Build a list of industry sectors/ business types that is commonly recognised and can be scaled out
• Prioritise that list in order of maximum benefit to the individual in making the data therein portable
• Build a related list of the data attributes that we’d wish to see become portable from those organisation types
Discuss the various technical means to enabling portability, and agree a recommended technical approach

Draft Report

Draft Technical Specification

Iain Henderson


"An Analysis of How to Deliver Maximum Data Portability under GDPR"

Technical Specification:

"A Specification for Data Portability Under GDPR"


This report reviews the history and current status of data portability project work in order to synthesis that into a recommended way to deliver maximum data portability in the context of the upcoming deployment of the General Data Protection Regulation (GDPR)

Draft Technical Specification

This specification, if followed by an organisation (data controller), will enable an organisation t the General Data Protection Regulation (GDPR), and ensure that the organisation maximises the portability of the data in question.

Status: Active; Inactive; Archived. Sub-status: Document published; Public review; Development; Formation.