Date
May 20, 2014
Attendees
John Wunderlich
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
...
Link to the Specification
...
Draft we are working on : Open Notice Consent Receipt
...
Spec v.01
...
The purpose of this specification 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.
The second part of the consent receipt is intended to draw out from the policies the minimum legal require for consent
Purpose
Jurisdiction and Contact Information for Data Controller
Jurisdiction data is stored in
Jurisdiction of the data subject
Consent Receipt Demo Button Review Terms
https://github.com/Open-Notice/consent-receipt/tree/master
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
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***
...
Notes/Things to address
- Implied or Implicit consent
- John suggest that we create space for implied consent in the original spec so that we can further extend the same spec in the future.
- Mark suggested that the URL (location of data controller) be defined as location of consent so that this could be the URL of the consent option and in the future be useful for location of physical spaces with policies/notices that equate to implied consent.
- Discussed extending section 2 with ( E & I) E for explicit, I for implied, and that we leave implied open, as for physical location we can make a PLocation field in the header, but leave this blank
- A separate section for Capturing the consent preferences from the user in the consent session
- e.g. DNT (at the moment this is in the header, but should this be moved to a section 4? A report section of the receipt ?
Discussion Items
| Time | Item | Who | Notes |
|---|---|---|---|
Action Items
...