Proposed Charter for Privacy by Design Documentation for Software Engineers (PbD-SE) TC

[Chet Ensign <chet.ensign@oasis-open.org>]

To OASIS Members:

A draft TC charter has been submitted to establish the OASIS Privacy by Design Documentation for Software Engineers (PbD-SE) TC. In accordance with the OASIS TC Process Policy section 2.2: (https://www.oasis-open.org/policies-guidelines/tc-process#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 17 October 2012.

OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.

A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.

We encourage member comment and ask that you note the name of the proposed TC (PbD-SE) in the subject line of your email message.

---
(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) The Names of the Member Section Co-Chairs
 
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