(objective: MVC - minimum viable consent to start with)

Introduction to the Consent Receipt Specification v.01

The purpose of the specification (or the consent receipt header)  is to standardise the recordation of consent and the  collection of consent specific policy links. As well as to make standard a link to withdraw consent.

Beyond this minimum viable consent the format should be extensible so that it can link to the legally consent notice requirements that are different amongst jurisdictions and industries. 

The first section (or header) of the consent receipt provides the basic needed information to record that a consent provision, and the policies under which it was provided. This header is what we need to acheive the objective of the specification. The MVC. 

The second part of the consent receipt is intended to draw out (from the policies) the minimum (or common) legally required notice requirements for consent (referencing the consent and notice map) and to display or link to these elements in the policy.  Either with a direct link to the relevant policy section or by scraping the policy and entering it here. All of the notice requirements for consent by jurisdiction and industry are to found in a reference document called the "Consent Notice Map". 

(Note: The theory being that the header provides the sources of information needed for the rest of the receipt ) 

The third section 

Consent Receipt Demo Button Review Terms

https://github.com/Open-Notice/consent-receipt/tree/master

Section 1

Terms in the Receipt So far (from Hack May 10) MVC Receipt
--Timestamp
--UserID
-- Location - ( Consent DialogUrl: (the url of the consent dialog)
-- Plocaton - (NA) 
--Revoke consent URL

--Policy URLS that have a been agreed to
--Json signature

• Preferences Captured from User

Section 2: (I for implied and E explicit)  (implied and explicit consent) 

• Purpose
• Contact of the Data Controller
• Jurisdiction in which Data Controller is held accountable (e.g. court) 
• Jurisdiction data is stored in
• Jurisdiction of the data subject
• Type of personal of personal information being collected

Section 3 Extensions

two types of extensions are predicted to be here. 

1. notice requirement extensions for jurisdictions, industry specific, or type of personal information specific notice requirements. 
2. Preference management links - e.g. DNT, Withdraw Consent, Block Use of Data use, (Note: these vary by jurisdiction)

Input from John for Spec

Consolidate above. 

Version: 1.0

**Abstract**

A consent receipt is a record of a transaction between a data subject and a data processor. In the transaction the data processor will have collected personal information from the data subject. The consent receipt documents what data processing the data subject has consented to, implicitly or explicitly, in the transaction. It can be provided to the data subject at the time of the transaction, or on request from the data subject.

**Specification**

( Key:value pairs?)

- Header info

- Processor ID 

- User ID

- Transaction ID

- Date

- Consent type

- Data collected 

- Data Processing consented to

***Expected information***

(From work to date)

Input into Spec - May 10

****

Link to the spec draft{string}

Receipt
--Timestamp
--UserID
--Consent DialogUrl: (the url of the consent dialog)
--DNT header (true; false)
--Revoke consent URL
--Policy URLS that have a been agreed to
--Json signature

****

Example:http://michielbdejong.github.io/consent-receipt/

****

{"@context":"http://opennotice.org/spec/receipt-0.1","receipt":{"timestamp":1399461895858,"userId":"info@smartspecies.com","dialogUrl":"http://example.com/signup","dnt":true,"revokeUrl":"http://example.com/quit","policyUrls":["http://example.com/terms","http://example.com/privacy"]},"jsonSignature":"tr0tberoijawflekrjg5wrgtbghdfgrt09rtgjw5tbrthe5ztntr"}