[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: PROPOSED AGENDA - PbD-SE TC - 20 March 2013
DRAFT MINUTES Privacy by Design Documentation for Software Engineers (PbD-SE) TC Meeting 20 February 2013, 1:30-2:30 PM EST / 19.30-20.30 CET Scribe: Gershon Janssen 1. Roll call, Agenda review Meeting Attendees: Members: Ann Cavoukian Gershon Janssen Dawn Jutla Sander Fieten Dennis Hamilton Harry Rhodes John Sabo Stuart Shapiro Aaron Temin Michael Willett Kevin MacDonald Observers: Colin Wallis Neil McKellar Guest: Kim Cameron This meeting quorates. Agenda was adopted, with the request to move agenda item 'Discuss PbD Principle #2' earlier into the agenda. 2. Approval of Previous Meeting URL: https://www.oasis-open.org/committees/document.php?document_id=48163&wg_abbrev=pbd-se Ann moved to approve the minutes of the 9 January, 2013 meeting. Seconded by John. Motion approved by unanimous consent. 3. Usage of Google Sites wiki Google Sites Wiki URL: https://sites.google.com/site/pbdsewiki/ The Google Sites Wiki is not a formal document repository for this TC, but just a tool for this TC to easily exchange documents. You are required to have a Google account to access the Wiki and only TC members are given access. Kavi is still our target repository for formal documents and TC deliverables. The TC was asked if the Google Sites Wiki is a useful place to put external documents / artifacts. Not everybody had a chance to look at the Wiki, but in general the Wiki looks very thorough. 4. Discuss PbD Principle #2: Privacy as the Default Setting Ann elaborated on principle #2. This is considered important as it is difficult to expect people to take active steps. PbD asks for privacy to be embedded as the default setting, so privacy can be assured. From academic literature we learn that default is what will be used; in this case we want this to be privacy. Fundamental of privacy is 'purpose'; primary purpose (reason for obtaining information) and secondary purpose (if beyond primary consent for collection, you need to obtain additional consent). Default in this context means users can be assured of privacy as built into the systems and it will be respected. New EU regulations (privacy data protection) have privacy as default, NIST has this as well as purpose specification. So this is not really a new concept. As a result, privacy protective systems delivered are with a default option for this. Dawn underlined that it is probably best to handle one principle at a time, so first is privacy as the default, next is purpose specification and use limitation. John noted that the concept does need more definition, e.g. create pseudo code to be more concrete so one can build this. But it is also required to tie this into other PbD principles. Let's say the default is okay with consent; what if the default changes? You are then required to re-obtain consent. An option might be to include a template expression delineating the default, so it is always clear what the initial intent was. The OASIS PMRM specification enables linking policy to data from an engineering point of view. Dawn likes this, though we need to think about how to express this in UML and welcomes ideas from TC members. Ann agrees that purpose specification and use limitation are the basis, but we need to get more granular. How to express the policy in the code itself, so future engineers can still understand what the initial intent was? Dawn asks if the consent directive might capture the purpose specification pieces and roll up in privacy by default? Ann notes that the problem with focusing on consent is that no one is taking the time to go through the 'fine print'. Default by the system is better. Kim (guest in this TC meeting) notes that we should not speak about data only; it should always be tied to an App or program. If you start from the App, rather than from the data, you almost always have a purpose. This simplifies things. People in the industry believe things start from the application; it is a simplifying idea. TC feels this helps in terms of proposed approach, though one cannot ignore the data. One App could actually handle many use cases, but still scope the use case from the application. People don't trust a use case but the application. We should be careful though to consider Apps only; consider e.g. large systems for health care, smart grids and electric vehicles. In relation to this discussion it was noted that the principle of data minimization should always apply to make systems safe. 5. Proposed Committee Work Plan (Appendix A) No meeting time left; item deferred. 6. Review of privacy engineering guidance and information resources/tools (Appendix C) No meeting time left; item deferred. 7. Assignment of Roles/Activities No meeting time left; item deferred. 8. Adjournment * Next meeting Next PbD-SE meeting is scheduled for 6 March at our regular 1:30 pm ET time. Due to unavailability of our chairs the following alternate date is proposed: Wednesday 20 March 1:30-2:30 pm ET The TC agreed to meet on Wednesday 20 March 1:30-2:30 pm ET. * Meeting frequency and duration Question came up if we need to increase the frequency and duration of our TC meetings? The time line from our charter is about 18 months. We might consider a duration of 1.30 hrs and increase frequency. * Sub Committees We might also explore the option to do things in parallel and to do work within Sub Committees. E.g. one the use case / App concept we talked about or templates for use cases.
Attachment:
DRAFT AGENDA - OASIS PBD SE TC March 20.doc
Description: MS-Word document
Attachment:
PbD-SE Privacy Use Case Template 12 March 2013.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]