[KI-LC] CISWG: Work Group Quarterly Report & MVCR Update

Mark Lizar mark at smartspecies.com
Wed Jul 22 17:25:41 CDT 2015

CIS: Work Group Update
Milestone in sight July 2015

As a result of a couple of years of discussion and work, the work group has set an objective of creating a usable consent receipt specification with the individual and their experience at the centre (human centric). The last edit has been updated in GitHub as version 0.7. We have worked on this for a while now and this last edit is the Alpha version of the Minimum Viable Consent Receipt (MVCR).
The consent receipt is a notice that is provided to people once they provide personal information to a data processor.  The information in this notice enables the data processor to meet the notice and consent requirements for using personal data. This creates an artefact that both the data processor and data subject can use to communicate about consent and manage it post consent.

As always, the devil is in the details and while there was early consensus at a conceptual level, this did not translate into an early consensus on the fields needed for such a specification. Because this is a net new data flow for Internet transactions, the group needed to develop an approach and understanding on a group level from scratch. The MVCR and its component parts have emerged from this process.

This next iteration of  the MVCR specification is designed to represent the minimum core requirements for digital consent, captured using a common format called a ‘receipt’ so that people can see track, and in the future, manage the collection disclosure of their own personal data.

From the start our objective has been to create a common set of legal, technical, and business components to create any type of consent receipt.  The creation of a candidate set of fields has enabled the writing of some alpha code to generate consent and implement receipts.

With this last revision the MVCR v.07 will soon be ready to present to the WG for review.
The work group is soon to moving on to work on MVCR v0.8 and testing the Alpha set of fields that have emerged to further stabilize the fields and implementations further.

With the Alpha MVCR we can start work on the legal considerations section to show how the MVCR can be used by other projects to bind the legally necessary elements for notice and consent to a variety of contexts.

The Process
The working group has decided to start with the *most* minimum set of fields needed. (A longer set would have been much easier to produce.)  By minimizing the fields and by clearly defining their parameters the group believes we are in the best starting position for the widest possible set of use cases and contexts.

In the latest version we have parked some fields for further discussion and possible re-integration into the specification.

These fields are as follows:
Remove consent transaction data
Remove consent context
Change Label - Id of natural person to “ID (or email) of the Receiver”
Remove - Link to short privacy notice
Remove consent payload
Remove Resource Server Identifier
Remove Oauth Scopes
Remove/What is —> Audience URI

The question for the fields that have been cut from the Alpha is whether they they belong in the MVCR profile. The group knows that the MVCR meets a minimum set of requirements but that a more generalized consent receipt specification will need to include more flexibility. It is not clear if that flexibility will be met by one or more of the following:
adding on to an existing  field
creating and using jurisdictional profiles
make additional field or sub-section to the receipt
(or better documentation)

We are now hitting a noteworthy milestone!

The move to version 0.7 of the specification and the alpha receipt generator gives us the chance to implement and move forward a bit faster.  Our first implementation is for CISWG participation agreement. The pre- Alpha consent button is already working.  (check it out) <https://kantarainitiative.org/signup/?selectedGroup=3>  It is working on our very own CISWG: Consent Receipt Generator  API, that can be seen at api.consentreceipt.org <http://api.consentreceipt.org/>, thanks to Justin and Sarah, bspke.io, Alexander and Oliver for putting the first versions of these together.

The working group can now start to test our assumptions in a consistent and common way, with a common set of components. This will ground future discussions and provide the data to resolve at least some of the tensions that are sure to arise.

Last but not Least - Launching as early as Aug 1.  — We  are polishing up our documentation and make the Kantara MVCR more open and accessible by planning the www.consentreceipt.org <http://www.consentreceipt.org/> website.

Thats all for now

Mark Lizar
CIS Co-Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/lc/attachments/20150722/b22ee247/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://kantarainitiative.org/pipermail/lc/attachments/20150722/b22ee247/attachment.sig>

More information about the LC mailing list