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

The official charter for this Technical Committee is provided below. (For additional information, see the Call for Participation that was issued when this TC was formed.)

  1. TC NAME

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

  2. 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.

  3. 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

  4. 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.
  5. IPR MODE UNDER WHICH TC WILL OPERATE

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

  6. 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.

  7. LANGUAGE IN WHICH THE TC WILL CONDUCT BUSINESS

    This TC will conduct its business in English.