OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Call for Participation: Privacy by Design Documentation for Software Engineers (PbD-SE) TC

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

[a] https://www.oasis-open.org/apps/org/workgroup/pbd-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)


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

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

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

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

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.


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

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

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.

[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


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.


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


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.


This TC will conduct its business in English.


(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 Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society

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


Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society

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

TC Administration information and support is available at

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]