Core Spec: Minimum Viable Consent Receipt (MVCR)- Specification

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 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	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 ([=]!:uuid:1111/[+]!:uuid:9999)
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)	[#receipt]!:uuid:1234<#location><$uri>&/&/"....."
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.	[#receipt]!:uuid:1234<$t>&/&/"2014-07-13T21:32:52"
Privacy Policy	The issuing entity's privacy policy (by reference to URI)	If not available, should provide a notice that it is missing	[#receipt]!:uuid:1234<#privacy><#policy><$uri>&/&/"https://..."
Cookie Policy	The issuing entity's cookie policy (by reference to URI)	If not available, should provide a notice that it is missing	[#receipt]!:uuid:1234<#cookie><#policy><$uri>&/&/"https://..."
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	[#receipt]!:uuid:1234<#short><#privacy><#notice><$uri>&/&/"https://..."
Do Not Track	Does the issuing entity respect DNT?	If not available, should provide a notice that it is missing	[#receipt]!:uuid:1234<#dnt>&/&/true
Sensitive	Categorize the information collected as senstivie or not	Medical, financial information for example	[#receipt]!:uuid:1234<#sensitive>&/&/true
Jurisdiction	The jurisdictions of the data protection authority for the data controller and data subject		[#receipt]!:uuid:1234<#jurisdiction>/$ref/[=]!:uuid:1111<#jurisdiction> [=]!:uuid:1111<#jurisdiction>&/&/"US" [+]!:uuid:9999<#jurisdiction>&/&/"DE"

Full Content (proposed development

Field Name	Description	Purpose/Explanation	Format of Field	Next Step	Comments
DP_Domain_Accountable for Consent	URL of the domain 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 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)
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	Url 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)

Consent Receipt (CR)

Data Subject(DS)

Data Controller(DC)

Bilateral Online Open Notice (BOON) - SS term for independently initiated two way communication over data controls

Master Data Controller - Individual who is the data controller and the data subject - In specific terms this term is to facilitate access and personal data control

Minimum Viable Consent Receipt Draft v.03