Date
Dec 19, 2013
Attendees
iainh1 NA (Unlicensed) Sends Apologies
Goals
The Agenda for the meeting today is to:
1. Cover at a high level the 3 parts to the scenario.
2. Discuss Part 1 and 2: Create development tasks and work towards a plan. (using Bit Bucket)
3. (time permitting) Discuss Part 3. Using the consent receipt ,
Discussion Items
| Time | Item | Who | Notes |
|---|---|---|---|
| 15 min | Go through Overview of Scenario | ||
| 15 min | Go through what has been done already on LEGALS.TXT | ||
| 30 min | Agenda | ||
| Valentino brings up issue what data is collected and what the purpose of the collection is about | |||
Mary - type of data and the policy around the data. Need to figure out good defaults. there is a lot that needs to be done in order to make the user experiencing interesting. Mark - Okay,, we should make it clear that this consent receipt is a method for opening. |
Immediate Plan of Action ( i will put this up on wiki)
Create the most basic demo to start with so we have a common starting point.
1. Part 1 of the scenario --> a website generating consent.txt - like legals.txt (links to policy + common consent schema)
This includes:
2. Putting the receipt generating button on a 3rd party website e.g. 'Consumers Voice' (Iain agreed to test )
3. Show the Delivery of the receipt to the website user
Valentino - Do you think we can add the consent specific fields to the legals.txt generator or should we create a consents.txt generator separately?
Valentino, Can you make a demo for just the consent receipt for use with one website? Should we make a separate website?
(Note: It would also be great to be able to link or directly reference the consent purpose, contact information, address inside the listed policies e.g. purpose on line 58 p.2)
Part 1 of the scenario is interesting enough for the initial purpose of this Scenario and the Summary Paper.
For the Summary
Mary, should we preface the summary paper mentioning that a receipt is a concept that is intended to be open source and can be used by itself but is intended to be used with current and future trust frameworks?
Perhaps explain that a consent receipt is a building block? I will talk to David to see what he thinks but the plan is to make a clear case for a consent receipt being required but missing privacy infrastructure on the internet with regulators. We can explain how a consent receipt will save time and money, it will increase the performance of policy, and will help open closed policies so that open source infrastructure can be developed to manage consent and personal information control. (maybe get a petition going to send to regulators)
Perhaps framing the scenario usability like:
A consent receipts demonstrates (or explores) a specification for common policy compliance across all jurisdictions for explicit consent notices and proposes a common framework for communicating consent preferences bilaterally independently from the provider. In this way is the specification is developed to deal with future compliance and usability issues. (Even without these 3rd party frameworks) A consent receipt functions to bridges compliance and personal information control on the Internet.
3rd parties (could be) registered with a consent receipt publishing tool when a company uses the services to publishes a (legals.txt or consents.txt) and by doing so will provide additional functionality to a consent receipt to enable greater service personalisation, personalised user experience and trust.
To deal with complex issues or if greater transparency is needed trust frameworks could be used with the consent receipt. In this way multiple frameworks can be applied together (mashup) and the individual can be the point of integration using them as needed. In this way a consent receipt promotes interoperability of personal information controls across jurisdictions and technical platforms.
Here are some examples of 3rd party frameworks we might consider extending the Demo with in the future.
1. Common Terms
2. NTIA - Short Notices
3. P3P ? (Mary are you up on P3P?)
4. Privacy Icons
5. Citizen Me
6. Privowny
7. TRUSTe
8. UMA
9. Open ID
10. TOS Dr
11. Safe Harbour
All of these can conceivably be added to a consent receipt and distributed on scale to the individual user in context of existing consent process online. (note: all of these trust framework providers might be interested in their own receipt publishing tool but would use the same schema specification we are proposing to be a standards candidate. )
For the Schema:
Action: I will send email to David and work on this. Mary Can you please send me links to Davids FIPPs work?
Action Items
- iainh1 NA (Unlicensed) (will provide update tomorrow on Developer Assistance)
- Mark Lizar (Unlicensed)