Core Spec: Minimum Viable Consent Receipt (MVCR)- Specification

Related Documents:

• CISWG: Consent Requirements Map: (spreadsheet of laws/principles for receipt and data control R&D)

• Open Notice: Mockup of a Consent Receipt: (A first MockUp of the consent receipt record)

...

The objective for a Minimum Viable Consent Receipt (MVCR) is to provide jurisdiction-ally appropriate consent related information in a common standard format.

Background

The Current Situation

Privacy policies are, by and large, written by data collectors and data processors to enable them to use personally identifiable information without running afoul of regulations that provide individuals some level of privacy protection. In essence, individuals who ‘click through’ existing privacy policies are thereby giving up their privacy rights and may be allowing data about them to flow freely in ways that many would not agree to were they to read the privacy policies in full. The myth is that privacy policies provide notice to people, and that they subsequently consent to what is described in those policies.

The Problem

Privacy policies are static statements that are closed to input or modification from the user. This suggests that there is little or no ability to manage consent because all users are functionally the same. This simplifies operations and minimizes risk for organizations but prevents people from managing data controls for information sharing.

Privacy policies are there because they are required in many jurisdictions. Every organisation that collects, uses or discloses personally identifiable information (PII) requires ‘consent’ (or an exception to consent such as ‘public safety’) to be obtained after giving ‘notice’ in a policy. This has created a cumbersome policy infrastructure that does not obtain meaningful consent and needs to evolve. At this time, there is no common format for standard consent and data control information and without this people have to manage their own data and track their consents in an ad hoc manner. The complexity and overhead of doing so effectively prevents anyone from doing so.   

Closed Policy

At the core of this issue is the fact that each policy is created as a unique document serving the needs of one organization. Each policy has its own structure and, by and large, this means that consent for all the individuals is processed in an aggregate, rather than an individual manner. Since there is no ability for an individual to grant, modify, or withdraw their consent except (occasionally) on an all or nothing basis consent is not, in most jurisdictions, informed and is therefore invalid. And even where the ‘one size fits all’ consent of a given organization matches the expectations of a given individual, most organizations will state that the policy can change solely on their initiative without consultation with the individuals whose information may be affected by the change. When policies materially change consent is no longer informed and may therefore fail to be legally compliant.

An open notice is a fundamental tool to address the asymmetric nature of the existing closed privacy policy environment and make granular individual consent as called for by privacy and data protection legislation operationally feasible.   

A consent receipt standard spec is a standard format designed to address these basic operational issues with a common format. With a common format, interoperable solutions can be developed at scale for all stakeholders. For example: If policies that manage consent have changed,  a consent receipt can be used to update the consent so that it the individual is informed. If this is not possible, a consent can be withdrawn or, an individual can update the consent themselves with an alternative data controller.

Format Specification Overview

A consent receipt is a record of a consent transaction between a Data Subject(DS) and a Data Processor (DP). The elements of the transaction involve the provision of notice and obtaining consent (or the assumption that use implies consent). The consent receipt documents what data processing the data subject has consented to, implicitly or explicitly, in the transaction. A consent receipt is provided to the data subject at the time of the transaction or on request from the data subject.  A consent receipt is intended to be used by all parties to manage the consent as policies for all stakeholders change over time.

...

For the DP the receipt serves notice of when material changes to data processing, provides a incredible tool for innovation enabling new and custom consent options, and is a needed tool that is required when an update to an existing consent is legally required.  

...

For the DS the receipt provides a way to maintain the consent, if the DP has not maintained it then the DS can maintain it independently, and even provide a self maintaining profile. Or withdraw consent.

...

The receipt produced is in effect an Open Notice as the native function of the receipt is to enable independent data control communication.  

...

Draft, background document can be found here,

Minimum Viable Consent Requirements

By its format and structure the MVCR is intended to provide the basic information to review further the compliance of policy for consent. The MVCR is a record in a standard format. As a result it can be further extended by jurisdiction, data type and additional context. A basic consent receipt will assure a basic level of general regulatory compliance for consent.  It will do this by being open, accessible, extensible and providing a standard format to develop a higher quality of consent and policy usability, data privacy law usability.

MVC Contents

This may end up being an XML document, but for now some basic Key:value pairs will provide an initial framework

Required Content

Header Information

• DP Domain:Domain URL

• DS Consent Preferences: {array to be determined}

• Processor ID: Listed DP

• User ID: Consenting identifier

• Transaction ID: GUID

• Sequence #: 0 for new receipt +1 every time it is used

• Use Reference: type of use ID

• Date:TimeStamp

• Consent type: Explicit, Implied, Exception

• Policy URI’s: PP, TOSA, Cookies

• Data Processing consented to: Purpose

• Address & Contact details of DP

• IP of DS

• Data Type: Personal Information(PI), (SPI) Sensitive Personal Information (Y/N)

Extended By Other Services

• Jurisdictional specifics

• Reputations

• Icons

• Short Notices

• Trust Frameworks

...