Contents

---

Frontmatter

Status

First draft v0.04 for a complete outline for v.05 (note: first v.1 should be a functional spec by example)

Action Items

Version Tracking

Note to Collaborators

• Before you save please note what you changed in the field provided to the left of the save button

• For any structural changes to the tables or format please request these changes in the comment box, not by directly editing the spec itself

Links to Dependent Documents

• Latest Consent Receipt Template

• Example 1: Open Notice Receipt Implementation

• Example 2: Respect Network PClound Implementation

• Ext Example: 3rd Party 

• Compliance Audit

• MVCR Consent Notice Legislation Map

• Hackathon Video and  Convergathon Hack Notes from July 12&13 2014 -->

• Scale of Compliance Use to measure the legal compliance of a consent receipt

Respect Network (RN) Technical Demonstration:

• Store a Consent Receipt in your RN personal cloud using XDI: http://amazon-respect-consent.herokuapp.com/

• List Consent Receipts in your RN personal cloud: http://open-notice.github.io/respect-network-receipts/

---

Introduction

A minimum viable consent receipt to document consent on the Internet is intended to serve the same purpose as a receipt for a cash transaction. It will provide a record of a transaction where notice of intent to process personal information is provided and consent for personal data processing is returned. Receiving a consent receipt immediately after a web, mobile or other internet based transaction provides an individual with an opportunity to confirm and, if needed, challenge collection of their personal information. Similarly, the consent receipt provides the data controller a clear signal as to what they can and cannot do with that person's information. The consent receipt provides protection for both sides against misunderstanding and can demonstrate compliance with regulations in the jurisdiction in which it was issued.

The MVCR will enable simple two party personal data transactions to be recorded by both sides (above). Extensions and developments of the consent receipt infrastructure will allow auditing and third party (including regulator) validation and confirmation of consent notices for compliance.

Background

The Open Notice Initiative is an effort that calls for open consent practices. This has resulted in the development of this specification for a Minimum Viable Consent Receipt (MVCR).

Overview

This specification creates a common format for provisioning consent receipts. The Minimum Viable Consent Receipt Specification will provide organisations with the ability to create and provision a record of consent. Proper construction of a consent receipt will require the record to be based on the minimum notice requirements for the jurisdiction in which the organization is operating (e.g. the jurisdiction of the data controller and internet location where the consent is located) 

In addition to the specification for the MVCR, this document provides a simple audit and compliance scale to show by example how to assess the extent to which an issued consent receipt (CR) meets the standard of a minimum viable consent receipt. 

The MVCR will be extensible so that it can include items such as extended notice compliance details, operational context, and utlised as a channel trusted architecture, services and Privacy Enhancing Technology:

1. Consent notice details can be appended to the MVCR to accommodate different personal data sensitivity, data sharing and additional contextual compliance requirements.  

2. A context field is a field in the MVCR indicating that there are contextual conditions and exceptions to consent that can be listed and applied by an organisation to the context of receiving consent (e.g. medical emergency overrides).  In the MVCR the context is a flag with yes or no. If yes, the provider is stating that they implement a check list of contextual consent requirements. Additional contexts can also be added to a consent receipt. 

3. Organisations can append trusted services links/icons to the receipt and further extend the assurance provided to capture multiple consent notice types e.g. cookie, terms of use.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.^{[1] (https://en.wikipedia.org/wiki/Behavior-driven_development)}

A key aspect of 'specification by example' is creating a single source of truth about required changes from all perspectives. This document is that source for the MVCR.

Objectives

The aim of this specification is to produce a receipt in a format that includes links to the policies asserted in the consent receipt. This will require an 'open notice' framework so that the policies can be verified and validated by third parties and regulators.

1. An organisation can use the MVCR to self assert that they are providing notice and getting implied consent in compliance with their policies and applicable regulations

2. A service user (individual) can save the  MVCR to a personal data store and self assess if the receipt is compliant with the policies and practices of the organisation

Interoperability & Scalability

• Interoperable: a common format enables the consent provisioner (the individual) to mange consent globally, interoperability

• Open Notice is currently working on an open source Open Consent Registry (OCR) which will be a customisable registry that  automates the functions required to provision, process, update and use consent receipts at scale.

Glossary

Minimum Viable Consent Requirements

The Minimum Viable Consent Receipt (MVCR) provides information contained in data fields that are used to link to the consent policy of the Data Controller in effect at the point consent is provided. (see Example1: Personal Cloud Storage of Receipt)

Note: For the consent receipt to be auditable and verifiable the consent policy must be accessible by any entity with the URI for the policy. Subsequent changes to the policy should not invalidate the URI for the policy in effect with the CR was issued. 

MVCR enables organizations to self-assert compliance with legislation and their own policies. The open notice (URI) provides this assurance in a transparent manner. To be compliant, a DC provides an auditable self-asserted MVCR which states that the DC will implement the contextual notice requirements listed in that MVCR. Most Data Controllers that identify the information that they collect, specify how it will be used, and that commit to not share personally identiable information with 3rd parties and to not collect sensitive personally identifiable information will be in compliance with most standards. If a DC does share personally identifiable information and/or collects sensitive personal information, an org can develop a custom extension, use an existing standard or register their consent receipt with  trusted service providers. Trusted Service providers can provide assurances and audit frameworks that enable compliance with more stringent and complex obligations for sensitive information and/or 3rd party disclosure.

A MVCR that demonstrates compliance will assure a level of basic regulatory compliance and provide a communication channel for consent and notice.  It is a digital record that both parties have. A human readable consent receipt should make sense at a glance, enable one click links or contacts with a data controller contact, and enable easy access to statements about purpose(s) and trust.  (Note:Advanced applications would enable in context control of consent and use of data.)  The receipt specifcation focuses on the  minimum visual (human readable) format and a the specified machine readable record that can be aggregated, audited, and visualised. This open format can then be used by other projects to provide a record (visibility to trust services and PETS) In conjunction with other existing systems a consent record can be effective self-regulatory facilitator addressing many challenges with simple transparency of data control. 

 

MVCR: Consent Notice Fields

 

The MVCR Format Notice Requirements are currently in progress. The full reference table can be found here. The table below may not be current.

Extensions for the MVCR

An extension can be appended to the MVCR to enable an organization to meet policy or other goals that are not regulatory requirements, but may be deemed to be best practices, or provide a better user experience for the data subject.

Extension Types

 

Core Extensions

In each jurisdiction, there are sensitive types of personal information found in privacy and data protection law.  Each sensitive type corresponds to a jurisdiction, is defined by an industry, and has prescribed context requirements for the use of a notice.  Core extensions can be added to the MVCR to meet more complex notice requirements and meet the requirements of multiple regulatory jurisdictions.

Core extensions can be used by policy makers to localise the use of consent notices to operational contexts and more granular applications of enforcement.

Operational Context (OC): Legal Requirement for the MVCR Context (in progress)

This is essentially a check list of provisions for the implementation of a consent notice. It will be used to provide assurance that the consent is fair and reasonable. There are specific and existing policies that are used to create this checklist. Many jurisdictions have prescriptions for the text required to accompany specific types of consent as terms defining those requirements. This is also the case with notice requirements.

As a part of creating a receipt for a data subject an organisation displays that they have agreed to implement (or not), the OC requires a checklist accompany the receipt. This functions as a flag: yes or no,  If yes, then there is a self assertion that the notice will be provided in a fair manner with all of the required considerations as prescribed in law in that jurisdiction.  This is then reflected on the consent receipt.

Instructions: This is a self asserted option, the Operational Context is a yes or no flag that the receipt provisioner turns on or off.  Operational context is dependent on the location of consent, the use of personal data, the origin of the data, and type of data provided. As Context of a consent can vary significantly operational requirements will also vary.  

 

Fair & Reasonable Consent Conditions

This table documents the checklist of elements for Operational Context.

Trusted Services

3rd party trusted services can also be used to extend the compliance or trust inherent to corporate process and these can be added in the form of linked Icons to a MVCR.

MVCR Proposed Extensions Table (in progress) 

These are the extensions tables.  This is an active list of extensions being planned and/or developed  need to include the name of the filed, have a description, context, benefit, and examples.

The various table currently include. 

 

Re-Usability

Re-Usability of a consent may come from adding a protocol, or a compliance level, or a receipt capture option. In the table below, a 'Consent Receipt Request' extension is listed-- this was developed at the Data privacy Legal Hackathon, Feb 2014. 

Extension Road Map

List of current or planned extensions