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)
...
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.
...
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
| Field Name | Description | Purpose/Explanation | Format of Field | Example | Legal Reference for Field | Tech P3PRef | MVCR? (y/n) | Next Step | Comments | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DP_Domain_Accountable for Consent | URL of the domain Accountable for Consent | Header/Admin/entity identifier | ||||||||||||||||||
| ConsentPref_ThirdParty | Yes/No share with 3rd partie | |||||||||||||||||||
| ConsentPre_etc | ConsentPref from P3P | Comment by John; Comment by Mark etc | ||||||||||||||||||
| Consent type: Explicit, Implied, Exception | Assumed Explicit consent fro alpha version | |||||||||||||||||||
| Data Processing consented to: Purpose | ||||||||||||||||||||
| Processor ID if different than Domain Id : Listed DP | The identification of the data processor | entity in charge | N | |||||||||||||||||
| 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 | ||||||||||||||||||||
| Date:TimeStamp | time and date of consent | |||||||||||||||||||
| Policy URI’s: PP, TOSA, Cookies | URI's pointing to source for Policies | |||||||||||||||||||
| 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 | |||||||||||||||||||
| 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
...