Fwd: [members] Call for Participation: Privacy by Design Documentation for Software Engineers (PbD-SE) TC

May be of interest to some PING folks.

-------- Original Message --------
Subject:  [members] Call for Participation: Privacy by Design Documentation for Software Engineers (PbD-SE) TC
Date:  Mon, 22 Oct 2012 12:18:17 -0400
From:  Chet Ensign <chet.ensign@oasis-open.org>
To:  tc-announce@lists.oasis-open.org, pbd-se@lists.oasis-open.org, members@lists.oasis-open.org
CC:  Carol Geyer <carol.geyer@oasis-open.org>



OASIS members&  interested parties,

A new OASIS technical committee is being formed. The OASIS Privacy by Design Documentation for Software Engineers Technical Committee (PbD-SE) has been proposed by the members of OASIS listed in the charter below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC's first meeting.

The eligibility requirements for becoming a participant in the TC at the first meeting are:

(a) you must be an employee or designee of an OASIS member organization or an individual member of OASIS, and

(b) you must join the Technical Committee, which members may do by using the Roster "join group" link on the TC's home page at [a].

To be considered a voting member at the first meeting, you must:

(a) join the Technical Committee at least 7 days prior to the first meeting (on or before 28 November 2012); and

(b) you must attend the first meeting of the TC, at the time and date fixed below (5 December 2012, 1:30 pm EST).

Participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties. Non-OASIS members who wish to participate may contact us about joining OASIS [b]. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository and public comments facility, which will be linked from the TC's public home page [c].

Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.

----------

[a] https://www.oasis-open.org/apps/org/workgroup/pdb-se/index.php


[b] See http://www.oasis-open.org/join/

[c] http://www.oasis-open.org/committees/pbd-se/��
---

(1) Charter of the TC

(1)(a) TC NAME

OASIS Privacy by Design Documentation for Software Engineers Technical Committee (PbD-SE)

(1)(b) STATEMENT OF PURPOSE

The purpose of the OASIS Privacy by Design Documentation for Software Engineers (PbD-SE) is to provide privacy governance and documentation standards for software engineers.

The main objective of the PbD-SE will be to facilitate privacy governance processes in organizations that conduct software development. This will be achieved by developing documentation standards that address privacy governance for software engineers. Such documentation will serve to guide software organizations interested in embedding privacy into the design and architecture of IT systems, without diminishing system functionality.

The protection of privacy in the context of software design requires normative judgements to be made on the part of software engineers. It has become increasingly apparent that software systems need to be complemented by a set of governance norms that reflect broader privacy dimensions.

The complex and rapid nature of technological change implies that privacy must ideally become embedded, as the default mode of design and operation, into software design. This is the central motivation of PbD which is proactive in nature and aimed at preventing the privacy harm from arising in the first place.

PbD prescribes that privacy be built directly into the design and operation, not only of technology, but also of operational systems, work processes, management structures, physical spaces and networked infrastructure. As a framework for strong privacy protection, PbD’s focus goes beyond strict technical compliance, encouraging organizations to both drive and demonstrate their commitment to privacy.

PbD is characterized by the following 7 Foundational Principles:

1. Proactive not Reactive; Preventative not Remedial

The PbD framework is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events, well before they can occur. PbD does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred − it aims to prevent them from occurring altogether. In short, PbD comes before-the-fact, not afterwards.

2. Privacy as the Default Setting

We can all be certain of one thing − the default rules! The power of the default cannot be over stated. PbD seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice by default. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy − it should be built into the system, by default.

3. Privacy Embedded into Design

PbD is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact. The result is that privacy becomes an essential component of the core functionality being delivered. Privacy is integral to the system, without diminishing functionality.

4. Full Functionality – Positive-Sum, not Zero-Sum

PbD seeks to accommodate all legitimate interests and objectives in a positive-sum “win-win” manner, not through the dated, zero-sum approach, where unnecessary trade-offs are made. PbD avoids the pretense of false dichotomies, such as privacy vs. security, demonstrating that it is possible to have both.

5. End-to-End Security – Full Lifecycle Protection

PbD, having been embedded into the system prior to the first element of information being collected, extends securely throughout the entire lifecycle of the data involved — strong security measures are essential to privacy, from start to finish. This ensures that all data are securely retained, and then securely destroyed at the end of the process, in a timely fashion. Thus, PbD ensures cradle to grave, secure lifecycle management of information, end-to-end. There can be no privacy without strong security.

6. Visibility and Transparency – Keep it Open

PbD seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact, operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent, to both users and providers alike. Remember, trust but verify!

7. Respect for User Privacy – Keep it User-Centric

Above all, PbD requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric – respect for the user is paramount.

While Governments, industry, and researchers internationally accept the principles of PbD (http://privacybydesign.ca/), one key aspect of privacy that has not been addressed in policy making, is how software engineers can execute PbD principles throughout the software development life cycle. This development would be invaluable and offer much needed guidance to software engineers.

(1)(c) SCOPE OF THE TC

The software industry standard for modeling and designing software systems and services is the Object Management Group's Unified Modeling Language (UML). PbD-SE can form a much needed privacy extension/complement to the UML standard, and serve as a complement to the Oasis eXtensible Access Control Mark-up Language (XACML), and the Privacy Management Reference Model (PMRM). Some of the guidelines for a standard that embeds privacy directly into the analysis and design phases of software development are as follows:

1. Establishing privacy objectives and requirements that satisfy the 7 Foundational Principles of PbD, as noted above.

2. Software analysts and designers should use and document a Privacy Impact Assessment (PIA) for any new software service, preferably the PbD-PIA.[1]

3. Ensure that software developers integrate privacy requirements (e.g. need for notice, disclosure, obtaining user consent, user access, data minimization, data security, and others as determined by the PbD principles) into functional use cases for software products and services.

4. A misuse case should be developed for each use case that deals with the handling of personally identifiable data. The misuse case should focus on potential privacy and security violations. A misuse case, the inverse of a use case, focuses on how a user can commit a malicious act against the system. In a similar vein, a misuse case may be developed to examine all non-authorized leakage of users’ personal data.

5. Ensure that privacy interface design guidelines, such as the 7 Cs (Comprehension, Consciousness, Choice, Consent, Context, Confinement, and Consistency)[2] are incorporated into interface designs and are well documented.

6. Ensure that attention is paid to the distribution and linkage of personal data between entities in class diagrams. When design-level classes are created, an intermediate level of “Privacy by Design” classes may be layered into the class mappings.

7. Ensure that Privacy Services (e.g. for Audit, Data Usage, Validation, Security) are integrated into behavioral communication diagram artifacts such as scenario diagrams.

8. Ensure that an internal independent review unit conducts reviews of all analysis and design documents, e.g. use cases, misuse cases, interface design, class diagrams etc, for explicit adherence to privacy guidelines.

9. PbD-SE is proposed as an effort to develop a standard for governance processes and documentation of privacy-enhanced software engineering artifacts at the software systems analysis and design levels. PbD-SE will not address documentation at the implementation level, although this is a logical extension, but is deemed out of scope of this TC’s work.

References
[1] P. Jeselon and A. Fineberg (2001), “A Foundational Framework for a PbD-PIA,”available at http://tinyurl.com/9btd9ld

[2] Dawn N. Jutla, Peter Bodorik, "Sociotechnical Architecture for Online Privacy," IEEE Security and Privacy, vol. 3, no. 2, pp. 29-39, March-April 2005, doi:10.1109/MSP.2005.50

(1)(d) A LIST OF DELIVERABLES AND PROJECTED COMPLETION DATES

The key deliverables of the OASIS Privacy by Design Documentation for Software Engineers is developing a documentation standard that ensures software developers can integrate PbD principles into software analysis and design documentation, such as, but not limited to, functional use case diagrams for software products and services, and comprehensive misuse cases. Estimated completion date is 12 – 18 months after the formation of this TC.

- PbD documentation for software engineers: Define a standard specification for software tools that engineers can use to aid in producing documentation and to show compliance with the PbD principles, and privacy regulations, throughout the entire software development life cycle.

- Develop misuse cases that deal with the handling of personally identifiable data. The misuse cases should focus on potential privacy and security violations.

- Develop envelope design artifacts for privacy processes or services that can be integrated into documentation such as scenario diagrams.

- Develop procedures to be used by internal independent reviewers in order to conduct reviews of all analysis and design documents, e.g. use cases, misuse cases, interface design, class diagrams, scenario diagrams etc., for explicit adherence to PbD guidelines.

(1)(e) IPR MODE UNDER WHICH TC WILL OPERATE

This TC will operate under the Non-Assertion Mode of the OASIS IPR Policy.

(1)(f) ANTICIPATED AUDIENCE OR USERS OF THE WORK

The PbD-SE audience includes, but is not limited to, software engineers, privacy policy makers, privacy and security consultants, privacy managers and executives, auditors, project managers, regulators, IT systems architects and analysts, and other designers of systems that collect, store, process, use, share, transport across borders, exchange, secure, retain or destroy personal information. In addition, other OASIS TCs and external organizations and standards bodies may find the PbD-SE useful in documenting privacy management analyses and designs in their context.

(1)(g) LANGUAGE IN WHICH THE TC WILL CONDUCT BUSINESS

This TC will conduct its business in English.


(2) NON NORMATIVE INFORMATION

(2)(a) Identification of Similar or Applicable Work

PbD-SE has relationships to the OASIS Privacy Reference Management Model (PMRM) and the OASIS eXtensible Access Control Markup Language (XACML) work. However, in its scope, PMRM does not address a future standard for privacy extensions to software modelling tools that engineers can use to embed privacy into their systems and services analyses, software designs, and documentation. Neither do UML and XACML. This is the gap that the proposed PbD-SE fills.

The Privacy Reference Management Model (PMRM) shows the relationships among privacy regulations, privacy policies, privacy best practices, privacy guidelines, privacy control standards, operational privacy services, technical privacy architectures, and implementation mechanisms for privacy. PMRM also provides a methodology that defines a set of privacy services that are useful to any stakeholder engaged in privacy management, including privacy managers, auditors, risk officers, policymakers, business process analysts, systems architects, quality assurance personnel, and software and service developers. Thus stakeholders can use the methodology to perform thorough privacy management analyses in a wide variety of contexts, from executive management to unit-level software testing for privacy compliance.

PMRM users may examine existing documentation, for example Use cases, that may or may not be represented using UML (and the proposed PbD-SE deliverables in future) in several steps of its methodology. Indeed, software developers and system architects can use both the PbD-SE tools and PMRM methodology as synergistic and complementary high-level tools to aid in privacy engineering and governance during the systems analysis and design cycle for new software systems or services. The PMRM will undoubtedly refer to XACML as it develops the mapping of technical mechanisms to its PMRM services. Similarly the proposed PbD-SE is expected to interface with XACML as PbD-SE documentation may refer to XACML’s core policy models at the software analysis and design level. However, XACML’s strength and focus is in access control at a policy implementation level, and not on privacy embedding in the software analysis and design stage of the SDLC, and its documentation as PbD-SE addresses. XACML provides for complementary documentation support at the implementation level for software engineers. Thus a future PbD-SE standard will be complementary and valuable to both the PMRM and XACML efforts in operationalizing privacy in systems and software services.

(2)(b) The Date, Time, and Location of the First Meeting

The first meeting is scheduled for Wednesday, December 5th, 2012, 1:30 p.m. EST via teleconference. Sobey School of Business at Saint Mary’s University, Canada, will sponsor the teleconference.

(2)(c) The Projected On-Going Meeting Schedule

Members will meet once a month for one hour, initially proposed to be on the first Wednesday of each month at 1:30 p.m EST, via teleconferencing sponsored by the Sobey School of Business. Face to face meetings will be organized as are necessary.

(2)(d) Names, electronic mail addresses, and membership affiliations of supporting Minimum Membership (proposers):

Dawn N. Jutla, dawn.jutla@smu.ca, Saint Mary's University

Ann Cavoukian, ann.cavoukian@ipc.on.ca, Office of the Information and Privacy Commissioner of Ontario

Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America

Drummond Reed, Drummond@xdi.org, XDI.org

John T. Sabo, john.annapolis@verizon.net, (individual)

Peter Brown, peter@peterbrown.com, (individual)

(2)(e) For each OASIS Organizational Member above, name, electronic mail address, membership affiliation, and statement of support

Dawn N. Jutla, PhD, dawn.jutla@smu.ca
“Recommended by leading governments, Privacy by Design (PbD) principles are embedded heavily in this TC’s vision for the evolution of privacy extensions in the analysis and design processes and their documentation within the SDLC. Standardized privacy extensions may be implemented in software tools. Such implementations are intended to help software organizations proactively manage and respect the privacy of multiple stakeholders or users (citizens, customers, employees) better. Further, future PbD-SE standard implementation will enable open, transparent, and positive sum approaches where software organizations can build in both productivity and privacy-by-default to create larger stakeholder value in trusted environments. Additionally, the PbD-SE’s output documentation will enable knowledge diffusion around how to embed lifecycle privacy in every industry’s software products and services. It may also serve as a standard for auditors to use to assess privacy compliance. To seed this TC’s work, I am pleased to contribute the original ideas and guidelines for privacy extensions to software modeling tools for software engineers as are found in the Scope of the TC section of its charter. As the Primary Representative of Saint Mary's University to OASIS, I support the PbD-SE Charter.”

Commissioner Ann Cavoukian, PhD, commissioner@ipc.on.ca
“As Information and Privacy Commissioner (IPC) of Ontario and as primary representative of the IPC to OASIS, I support the PbD-SE charter. Privacy by Design is a concept that I developed back in the 90’s, to address the ever-growing and systemic effects of Information and Communication Technologies, and of large–scale networked data systems. It advances the view that the future of privacy cannot be assured solely by compliance with legislation and regulatory frameworks; rather, privacy assurance must ideally become an organization’s default mode of operation. The IPC is pleased to contribute our 7 foundational Privacy by Design principles for use in the OASIS PbD-SE Technical Committee's work. We believe that this new PbD-SE TC will undertake important standardization work in providing tools for software engineers to embed privacy into their analysis and design documentation for products and services.”

Abbie Barbir, PhD abbie.barbir@bankofamerica.com
“As the primary for Bank of America I hereby lend support to the PbD-SE Charter.”

Drummond Reed, Drummond.Reed@xdi.org
“Privacy by Design (PbD) has caught worldwide attention and represents a paradigm shift in how necessary it is to be proactive about privacy. This is essential as we build a digital trust network where individuals may share identity and personal data with greater confidence that it will be protected and only used as authorized. The Privacy by Design Documentation for Software Engineers Technical Committee will provide valuable direction in this regard; it will provide structured documentation, templates and assessment procedures to make Privacy by Design achievable at the level of software code. As Secretary, XDI.org, an OASIS member, I am pleased to offer this Statement of Support for this important new TC.”

(2)(f) The Name of the Convener

Dawn N. Jutla, PhD, Sobey School of Business, Saint Mary’s University is the convener of the PbD-SE TC.

(2)(g) Member Section

No affiliation with a member section is proposed.

(2)(j) Proposed Working Title and Acronym (Optional)

PbD-SE – Privacy by Design Documentation for Software Engineers.

---

/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393






---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium communications.

Opt-out requests may be sent to member-services@oasis-open.org, however, all members are strongly encouraged to maintain a subscription to this list.