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)
This incorporates 3rd party sharing and purpose listing format
Hackathon Notes from July 12 2014 --> Convergathon Hack Notes July 12
Objective
The Open Notice Initiative is an effort that calls for an open, global and public infrastructure for consent-based notices. A key element of that infrastructure is the minimum viable consent receipt described in this document. Such a receipt will provide people with the knowledge necessary to make an informed choice about who gets their personal information and what they can do with it. This will be accomplished by providing an explicit record of the consent transaction from the web site to the user about what the user has consented to at the time of their initial transaction with the web site.
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.
...
the basic fields for recording open policy notices in a registry. With these notices people can easily obtain a simple record of consent, and use this independently to manage personal data control and access personal data organisations have.
The objective of this first specification is to list the fields that are needed to create a Minimum Viable Consent Receipt (MVCR) and its subsequent registry listing, for open notices, which the Open Notice Initiative is developing. At its minimum, jurisdiction of parties, location of consent provision, and location of data are critical components needed to provide information to various stakeholders.
In addition, the third party sharing of data, enabled by sharing a consent is a critical component for Consent & Information Sharing to be transparent. As suche a 3rd Party Lnk/Declaration format is also added below. This is in addition to the format for the MVCR.
The Alpha version of this draft is intended to be very focused on explicit consent online, and the ability for organisations to provide explicit consent. Our first aim is to research the state of play and compliance.
Background
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
Consent Receipt
| Field Name | Description | Purpose/Explanation | Format example (XDI) |
|---|---|---|---|
| Data Subject | Name or pseudonym of the user | Depending on the context could be full name, username, or pseudonym | Data Subject: Alice [=]!:uuid:1111 |
| Data Controller | Name of the entity issuing the receipt | Should be the entity/organization operating the service/web site that is collecting personal information | Data Controller: Amazon [+]!:uuid:9999 |
Third Parties | Names of third parties involved in the transaction |
This may end up being an XML document, but for now some basic Key:value pairs will provide an initial framework
...
An example would be a transaction with Amazon where the fulfilment of the order is done be UPS | Third Parties: UPS [+]!:uuid:8888 | ||
following lines all prepended with | |||
| Digital Location | The location from which the consent receipt orginates. Possibly the web page with the consent button | This indicates the 'point of consent' - hopefully a button where the user clicked "I agree" or "I consent" (i.e. the biggest lie) |
|
| URI Location | The domain of the organization issuing the receipt | This identitifies the organization accountable for the fulfilling the committements of the receipt/notice | [#receipt]!:uuid:1234<#location><$uri>&/&/"....." |
| Consent Type | What kind of consent has been received | To record the type of consent or whether there is an exception to the requirement for consent. | |
| Purpose | The purposes for which the personal information is being collected. | [#receipt]!:uuid:1234[<#purpose>]<@0>&/&/"We need to process your payment." [#receipt]!:uuid:1234[<#purpose>]<@2>&/&/"We need your data to prevent fraud." [#receipt]!:uuid:1234[<#purpose>]<@3>&/&/"We will advertise to you." | |
| Timestamp | When consent was obtained | To record when the user, either by implication or explicity, granted consent for the purposes described. | |
| Privacy Policy | The issuing entity's privacy policy (by reference to URI) | If not available, should provide a notice that it is missing | |
| Cookie Policy | The issuing entity's cookie policy (by reference to URI) | If not available, should provide a notice that it is missing | |
| Terms of Service | The issuing entity's terms of service (by reference to URI) | If not available, should provide a notice that it is missing | |
| Do Not Track | Does the issuing entity respect DNT? | If not available, should provide a notice that it is missing | |
| Sensitive | Categorize the information collected as senstivie or not | Medical, financial information for example | |
| Jurisdiction | The jurisdictions of the data protection authority for the data controller and data subject |
Full Content (proposed development
| Field Name | Description | Purpose/Explanation | Format of Field | Example | Legal Reference for Field | Tech Ref | Next Step | Comments | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DP_Domain_Accountable for Consent | URL of the domain Accountable for Consent where consent is provided Consent. If this is physical space, then physical location needs to be included, along with digital domain of service provider/data controler. | Header/Admin/entity identifier,location of domain, physical space where the consent is provided. | |||||||||||||||||
| Location: | is this a physical location | ||||||||||||||||||
| ConsentPref_ThirdParty | Yes/No share with 3rd partie | ||||||||||||||||||
| Third Party Sharing - Link List | A list of third parties, that data is shared with. | This is a critical element for having a consistent scope for data sharing and enabling people to manage/check third parties post consent. | html link, contact info, policy info | A format and form for Linking third parties needs to be created. | |||||||||||||||
| ConsentPre_etc | ConsentPref from P3P captured during the consent recording/transaction | This field is for capturing consent preferences at the point of consent. This is only used when making a live record of consent. | Comment by John; Comment by Mark etc | ||||||||||||||||
| Consent type: Explicit, Implied, Exception | Assumed Explicit consent fro alpha version | for live consent, this explicit, althought there are post, pre, consent notices and development which may need a different consent type. | |||||||||||||||||
| Data Processing consented to: Purpose | What are the top level purpose(s) for the consent | Note; There are some jurisdictions that require multiple consents for multiple purposes. | |||||||||||||||||
| Processor ID if different than Domain Id : Listed DP | The identification of the data processor | entity in charge | |||||||||||||||||
| User ID: | id (email) of the user in the consent form | non-repudiation | |||||||||||||||||
| Transaction ID: GUID | the specific consent ID | (or transaction id) | Sequence #: 0 for new receipt +1 every time it is used | time of consent, consent/policy updates, | |||||||||||||||
| Use Reference: type of use ID | Note how is this different than purpose? | ||||||||||||||||||
| Date:TimeStamp | time and date of consent | ||||||||||||||||||
| Policy URI’s: PP, TOSA, Cookies | URI's pointing to source for PoliciesUrl of policies, these are used to grab a copy of the policies and to store them in the registry record. | ||||||||||||||||||
| Address & Contact details of SP | Unless different DP this should be the same as the DP | ||||||||||||||||||
| IP of DS | IP of person making consent - Jurisdiction of the IP address | In order to compare compliance of policy of the Service provider against the jurisdiction of the individual | |||||||||||||||||
| Data Type: Personal Information(PI), (SPI) Sensitive Personal Information (Y/N) | Data sensitivity (privacy category) |
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
Glossary
Minimum Viable Consent Receipt(MVCR)
...