Minimum Viable Consent Receipt Specification
Draft version 0.6
Minimum Viable Consent Requirements
Extension Types (added as site specific fields)
Operational Context (OC): Legal Requirement for the MVCR Context
Fair & Reasonable Consent Conditions
Appendix: Requirements for Consent Receipt Code Generator
Front Matter
Status
Draft version 0.06 specification for MVCR Code Generator and Minimum Viable Consent Receipt Data Description
Action Items
@Mary Hodder to edit
@Mark Lizar to review and comment
Version Tracking
...
Version
...
Status
...
Writer
...
Editor
...
Notes
...
v.01
...
Done
...
Mark Lizar
...
Mary Hodder
...
Summary of Intent
...
v.02
...
Done
...
Mark Lizar Mary Hodder
...
John Wunderlich
...
Stakeholder Analysis
...
v.03
...
Done
...
John Wunderlich, Mark Lizar
...
Mary Hodder
...
Summary of Compliance Contents
...
v.04
...
Done
...
Mark Lizar, Markus Sabadello
...
John Wunderlich
Mary Hodder
...
Spec Outline & Demo (Mark), Technical Walkthrough (Markus)
...
v.05
...
Done
...
John Wunderlich
...
Mary Hodder,
Mark Lizar
...
Word updating.
...
v.06
...
In process
...
John Wunderlich
...
Mary Hodder
...
Clean up.
Added Basic Use Case
Describe MVCR Generator
Executive Summary
To be written when draft completeMinimum Viable Consent Receipt Specification
Draft version 0.6
Status: T
Draft version 0.06 specification for MVCR Code Generator and Minimum Viable Consent Receipt Data Description
This is the first draft version of the MVCR that we plan to work collaboratively on using Git Hub Version Tracking
Scope
The objective is to develop a core consent format for the record of a consent transaction.
As a result this work is this specification is for the development of the Minimum Viable Consent Receipt. (MVCR)
The aim of this format is to pull out the core requirements for a consent to be legitimate, and to put it into a highly usable structure.
This version of the specification is being written for simple basic use on websites as the context.
This version of the consent receipt is for explicit consent in this context
The term ‘Minimum Viable’ in this context, the most basic and common requirements to record a consent found in regulation across jurisdictions.
'Consent Receipt’ - Consent refers to the act of clicking a check box and clicking an I agree button to complete a consent transaction.
Receipt refers to a copy of the consent transaction record
The objective of the consent receipt is to capture the minimum viable consent transaction specific information. This includes:
Contact information of Data Controller and digital identity provided by the consenter
links to policies explaining use of personal and sensitive personal data
a collection of the purpose(s) (like a collection of items being purchased)
YES or No Flags (compliant by defualt design)
3rd party data sharing
Collecting Sensitive Personal Information
Context Requirements Checklist
Extensions (for those that are not compliant by default)
Core Compliance/Legal Extension
3rd Party Extensions
Post Release of this version v.06 of the consent receipt specification we will be writing extension that greatly expand the scope and use of this Minimum Viable format. Extended so that it can address the notice and consent requirements for very complex data control issues by enabling people with consent management.
...
(Note: Extensions and developments of the consent receipt infrastructure, although out of scope for a minimum viable consent receipt, will be listed and made clear how the MVCR can and will be extended to allow auditing, third party (including regulator) validation and confirmation of consent notices for compliance.)
Glossary
Term | Definition | Example |
Consent Receipt (CR) | A record of a single consent transaction provided to the data subject at the point of consent. | This record is a summary of legal requirements of the notice provided at the point of consent about the collection, use and disclosure of information by a data controller, and has given consent for that collection, use and disclosure. |
Data Controller (DC) | The organization 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 provides identity and/or authentication information about the data subject. | |
Minimum |
| 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 jurisidction 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. | include health, financial, children’s data, sexual data, political/religious data, surveillance data, (note I think this should include participate in identifying SPII |
Trusted Services | A provider of Trust Product, like a Privacy icons,a certification for standard assurance, a reputation services, a trusted networks, trusted protocols, etc | |
Viable | Meets or exceeds regulatory minimum for notice in the jurisdiction where it is issued | |
Open Notice Framework | An Open Notice is a standard consent format for policy notice summaries as required by law. The use of an Open Notice is further facilitated by a framework which enables the independent use of the Open Notice. collection and opening of organisational privacy policies and terms some projects that do this exist already; E.g. TOSSBACK |
...
DC’s that share personally identifiable information and/or collect sensitive personal information can go beyond an MVCR and 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. (FootNote: These extensions are beyond the scope of an MVCR.)
Consent Notice Data
Field | Description | Example (XDI) |
Data Subject | Name or pseudonym of the Data Subject | Data Subject: Alice [=]!:uuid:1111 |
Sensitive Personal Data Flag (Y/N) | Flag to categorise the information collected as sensitive or not. Each jurisdiction has classifications of sensitive personal information (privacy): The generally include health, financial, child protection (>14), youth protection(>19 or >22), educational, religious, or political categorisations. May trigger additional legal notice and consent requirements | [#receipt]!:uuid:1234<#sensitive>&/&/true |
Data Controller | Name of the entity issuing the consent receipt. This is the entity accountable by law for the information collected. | Data Controller: Amazon [+]!:uuid:9999 |
Purpose | The purpose(s) for which the information is being collected. | [#receipt]!:uuid:1234[<#purpose>]<@0>&/&/"We need to process your payment." [#receipt]!:uuid:1234[<#purpose>]<@1>&/&/"We need your data to prevent fraud." [#receipt]!:uuid:1234[<#purpose>]<@2>&/&/"We will advertise to you." |
Privacy Policy | The issuing entity's privacy policy (either inline copy, or reference to URI) | [#receipt]!:uuid:1234<#privacy><#policy>&/&/"copy of privacy policy here" or
[#receipt]!:uuid:1234<#privacy><#policy><$uri>&/&/"https://..." |
Location of Consent | The location of the consent provision. from which the consent receipt originates.(i.e. The web page with the consent button.) | [#receipt]!:uuid:1234<#location><$uri>&/&/"....." |
Third Party Sharing | Flag whether data is shared with third parties. (Y/N) May trigger special notice or consent requirements | [#receipt]!:uuid:1234<#third><parties>&/&/true |
Site Specific Fields | Additional field or fields as necessary to fulfill the notice and other requirements that the Data Controller may need |
Minimum Viable Consent Requirements are a work in progress. On a per jurisdiction basis these can be added to the MVCR as site specific fields. The full reference table can be found here.
Extensions are appended to the MVCR to enhance the compliance, organisational objectives or user experience of the data subject.
...
Alice registers with a website, bob.com to donate to listen to bob.com’s podcast.
At or before the time that Alice registers with, or authenticates using a third party identity provider, to bob.com
bob.com display all the appropriate privacy policies in standard location of the website
3 secnarios for this use case
prior notice was given for consent and needs a receipt
current notice is given and requires a receipt
and cites, the notice and consent requirements of the regulatory regime in which the web site operates. For the the purposes of this this specification it is assumed that either prior consent receipt has been provided, that this is the first time a consent receipt is provided, or that this is a request for a consent receipt to be provided (or confirmed) will
consent receipt for bob.com website is code that is created via from and is put behind the consente receipt button,
This is previously made by filling out a form,
A consent receipt is provided at point of consent with a modified consent button
To be added
walk through of the creation and provision of a consent receipt that conforms to the data specification below.
The creation of web site will either provide, or offer to provide, the user with a copy of the consent receipt to complete the registration process.
The use case ends when the user accepts the consent receipt, or declines the offer.
Description Detail | Notes |
Related Requirements | The provision of a consent receipt enables data providers to demonstrate their compliance with regulatory requirements for notice and consent. |
Preconditions | Before a consent receipt can be issued the following conditions must be true:
|
Successful End Conditions |
|
Failed End Conditions | The data subject completes site registration with receiving being offered a consent receipt. |
Primary Actors | Data Subject Data Controller |
Secondary Actors | Identity Provider Open Notice Registry: A third party that provides validated information about the Data Controller’s compliance. |
Trigger | Data Subject provision of site registration information. |
Main Flow |
|
Extension | 2a: Data subject identity information is provided by a third party 5a: Data subject elects not to receive a copy of the consent receipt 6a: Data Controller does not store a copy of the consent receipt |
...
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/
Amazon Respect Use Case: With the Respect Network and Open Notice
(Note: Amazon Respect is a Fictitious organisation used here only as an example)
(http://open-notice.github.io/consent-receipt/amazon-mock/signup.html)
Implementation of consent receipt which is signed & created by a DC and stored in a personal cloud.
...