Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Date

May 20, 2014

Attendees

Goals

  • Consent Receipt Spec Intro Dev and review  - 10 min
  • review and further develop intro to the specification - 15 min
  • Define Terms - Michiel v. John terms - review the terms and approaches by both 
  • Tech Task - Create this  Specification in a CISWG Git Hub Page (with the CISWG License) (note: email sent to Oliver to do this)
  • Link spec to CISWG wiki (how should we do this?)
  • Plan the next steps to creating the specification and developing a working demo

Introduction to the consent receipt

Intro to the Specification: Consent Receipt Specification v.01

The purpose of the MVC 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.

The first section (or header) of the consent receipt provides the basic needed information to record that a consent 
was provided, and the policies under which it was provided. This header is what we have called in the past the MVC. 

The second part of the consent receipt is intended to draw out from the policies the minimum legal requirements for consent and to display these.  Either by a direct link to the policy section with the legal notice requirement or by scraping the policy. All of the notice requirements for consent by jurisdiction and industry are to found in a reference document called the "Consent Notice Map". (needs link)

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

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
--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

 

 

Section 2:

  • Purpose
  • Contact of the Data Controller
  • Jurisdiction for Data Controller
  • Jurisdiction data is stored in
  • Jurisdiction of the data subject


Section 3 Extensions

two types of extensions are predicted to be here. 

  1. notice requirement extensions for jurisdictions, industry specific, or type of personal inforamtion
  2. Preference management tools - 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)

 

 

Notes: 

 

  • Implied or Implicit consent ( 

 

 

 

 

 

Discussion Items

TimeItemWhoNotes
    

Action Items

  •  
  • No labels