The 0.6 version of the MVCR specification focuses on the requirements for the MVCR specification. Future versions of this specification will add additional material to allow for the technical implementation of an MVCR. As a result, this version of the specification has been reduced by removing material from previous edits, which will be added in according the stage and agreed roadmap of the MVCR in the CISWG.

Executive Summary

The Consent & Information Sharing Working Group (CISWG) is distilling a small, common set of consent requirements for information sharing that are salient across jurisdictions with Fair Information Practices based privacy instruments and standards.(ISO and ITPA footnote) These common requirements will constitute the minimum viable consent requirements, specifying the minimum required links, fields and data formats to meet the minimum obligations for information sharing.

The MVCR comprises the core Consent Receipt (CR) specification and specifically refers to the notices required for compliant consent to be valid when collecting personal information. This is currently managed by organisations separately, with bespoke policies that are closed to systematic use by an individual. The MVCR addresses this problem.

Problem Statement

Information sharing is a complex issue for organisations that require consent for the collection of personal information from individuals and have specific legal obligations related to the context and the collection of those data. These obligations require privacy policies and/or notices about how personal information may be collected, used, disclosed, retained and disposed of or deleted. As each organisation posts their policies in different locations, and often change the content and URI of the policies, this is systematically unusable. Each organisation has their own best practices, policy structures and policy formats. This results in a closed (or 'siloed') type of transparency, that violates the Openness (transparency and notice) privacy principles, is very costly to manage for all stakeholders and very difficult to regulate effectively.

Currently there is a static and binary notice and consent infrastructure that is regulated, yet neither usable nor suitable for its intended purposes. An individual is asked to perform beyond what is reasonable in the current context. They are expected to find and read policies, understand all of the information sharing relationships in context and anticipate the effects of their choices, and manage each consent and personal information relationship with their associated identities with all of these organisations. In other words, each individual is expected to understand what information is being collected about them, how it will be used and for what purposes, with which types of entities their information will be shared and understand the consequences. All of this is asked without having the ability to take a record and manage consent independently out of context. Meanwhile, in context, people are expected to keep track of all active consent, when making new consent agreements.

Information sharing is dramatically increasing, and so the capacity for people to manage information sharing and identity based relationships needs also to increase. A specification for a minimum core, generically viable consent can address specific jurisdictional requirements and provided evidence of compliance with ISO 29100 or other privacy frameworks.

Individuals' capacity to manage their privacy is increased if they are able to aggregate and manage consent & information sharing relationships with consent receipts. Organisations can use these receipts to standardize the consent experience. Consent receipts also provide a channel for organisations to advertise trust. Regulators may use standardized consents to understand whether requirements are being met.

Scope

The Minimum Viable Consent Receipt (MVCR) specification will provide a generic standard that provides a verifiable metric. It is intended to be used with CISWG use cases.

The 0.6 version of the specification further defines the requirements for a Minimum Viable Consent Receipt (MVCR). In this version, the scope is limited to covering when a user takes an action to consent to sharing information, noting that personal data will be collected in a consent transaction. This consent can occur before, during or immediately after their personal information is collected.

The receipt format is human and machine readable and may include icons. It will be accessible ie, meeting accessibility standards [[Section508 footnote and others]].

Stakeholders

There are three general stakeholder audiences for the MVCR which are referenced through this material:

People: People receive the consent receipt and may use this to track consent and exert control over information about themselves.

Regulators - (privacy and data protection enforcement) Regulators include but aren't limited to the FTC in the USA, the Canadian Federal and Provincial Privacy Commissioners, the EU Data Protection Regulators. Regulators may provide public processes for administration and enforcement of regulation in regards to notice and consent requirements.

In summary, this MVCR receipt specification addresses the requirements of these three stakeholder groups with the aim to provide a business infrastructure organizations will implement, that people can use and that regulators can enforce.

Intellectual Property Rights

This document is being developed by Kantara Initiative's Consent and Information Sharing Working Group; see <https://kantarainitiative.org/groups/ciswg/>. Participation is free and open, and all work contributed to the effort falls into the Reciprocal Royalty Free with Opt-Out to Reasonable And Non discriminatory (RAND) IPR policy <https://kantarainitiative.org/confluence/x/mQByAg>.

Kantara Initiative is a non-profit membership organization that connects businesses, consumers, governments, and citizens through innovations and programs that support more natively trust worthy on-line experiences. The mission of KI is to foster identity community harmonization, interoperability, innovation, and broad adoption through the development criteria for operational trust frameworks and deployment/usage best practices for privacy-respecting, secure access to trusted online services.

Generic Requirements (TBF v.06)

The word “SHOULD” indicates a recommendation and does not impose an obligation. The word "CAN" means that this is a common option.

The receipt MUST have a property to authenticate the origin.

The receipt MUST have an integrity protection property.

The audience SHOULD be restricted and transparent.

The receipt SHOULD be able to be transmitted over various transport protocols.

The payload MUST have a human readable section, and SHOULD have a machine readable section.

The payload MUST include the following properties:

Issuer

Date

Time

Direct contact information to data controller

Contain a static link to privacy policy; the user must have a permanent record of the text to which they agreed

Purpose (s)

YES or NO Flags

3rd party data sharing

Sensitive Personal Data Collection

Context

The payload SHOULD include the following properties:

A description of the types of personally identifiable information to which the consent applies.

The payload SHOULD include the following information:

the personal identifier used in the consent receipt

some or all of the personally identifiable information to which the consent applies

The receipt MUST be systematically usable and automatically discoverable

Receipts MUST contain the minimum information to enable request for more information, if required

Consent Notice Fields and Descriptions (TBF v.07)

The fields consists of:

Contact information of Data Controller

Identity provided by the individual

Link to privacy policy

The purpose(s) listed: itemised on receipt

YES or NO Flags

3rd party data sharing

Sensitive Personal Data Collection

Context Scope and Requirements

Consent Notice Fields and Descriptions (TBF v.07)

Term

Definition

Example

Consent Receipt (CR)

A record of a single consent transaction provided to (or obtained by) the data subject as a receipt.

This record is a summary of legal requirements of the notice and a capture of consent related data provided at the point of consent.

Data Controller (DC)

The organisation or individual that is accountable for the operation of the web site.

This is contact information for the management of consent.

Data Subject (DS)

The natural person that is registering on the web site.

This is typically when a person registers to get access to a web site service.

Identity Provider (IdP)

A third party that uses identity and/or authentication information about the data subject for access management.

Minimum

A Receipt will contain the purposes to which is consented to

The links to all policies that inform the consent and the contact information of the data controller.

Operational Context of Consent

The list of legal (best practice) requirements for notice for consent in the jurisdiction and context in which the consent is given.

This includes jurisdiction requirements as well as the contextual elements to the method of consent capture

Personally Identifiable Information (PII)

Any information that (a) can be used to identify the Data Subject to whom such information relates, or (b) is or might be directly or indirectly linked to a Data Subject.

Sensitive Personally Identifiable Information (SPII)

This a flag in the consent receipt that is used for what is legally defined as sensitive and protected data, this varies from jurisdiction to jurisdiction. For this type of data explicit consent is required and a consent receipt extension is needed for this functionality.

Minister of Economy Office, Japan (2014) Guideline for the online notice and consent from consumers, http://www.meti.go.jp/press/2014/10/20141017002/20141017002a.pdf. [Includes examples of a consent receipt in guidelines proposed in the context of ISO 29100]

Appendix A: Flags Defined (TBF v.07)

3rd Party sharing

Sensitive Personal Data

Operational Context (OC): Consent Context Scope & Requirements

As a part of creating a receipt for a Data Subject (DS) there are often legal requirements based on the operational content(OC). OC requires that a checklist accompany the receipt. This functions as a flag: YES or NO.

i.e.

If YES, there is a self-assertion that the receipt and company side consent management practices follow the legal requirements for fair and reasonable consent harvesting.

Operational Context - Defined by either jurisdictionally specific requirements or use case specific requirements. The OC also is a space/scope for company-side assertions (e.g. customer service, quality, etc.

Informing PII principals about the consequences, if any, of withholding their consent in whole or in part; and informing on the ways to withdraw consent

whether replies to the questions are obligatory or voluntary, as well as the possible consequences of failure to reply,

the existence of the right of access to and the right to rectify the data concerning him NOTE: Burying the privacy related notice obscurely in the other matters and having user accept it is a common privacy attack.

Audit Notes

is Consent is action based

is it an independent permission (i.e. only one policy with same scopes of purpose)

Meaningful Policy Changes Requiring a New Consent Receipt

Change in overview of the service

change the PII Controller

change PII items being collected

change the purpose of use to something outside the scope

change 3rd party- unless DS consented to scope of 3rd parties and this is within scope