Re: [pbd-se] comments on draft/questions

Hi Frederick:

Thanks for providing this feedback.

The specification is targeted at all software engineers. They may be working in (virtual) organizations or projects of all sizes. This includes software engineers working in platform teams. We can make that very clear in the spec language.

Here is another viewpoint to the UI issue you raise. A software engineer can document OR reference the documentation for any individual platform UI aspects of the software (s)he is responsible for - even when not having the full platform picture. However the platform owner(s) has/have the full picture and that entity/those entities would be responsible for assuring that their subcontractors or in-house teams document if the platform wants to claim auditable PbD compliance at the relevant PbD-principle level. I don't think that having multiple platform owners or providers, or lean incremental builds, provides a loophole for accountability or responsibility. We can discuss this later on the call.

Agreed - we can easily remove the future plans from the standards track working document. They were placeholders to show scope of the work.

Chat soonest...

Dawn

______________________________________________________________
Dr. Dawn Jutla, PhD

Professor of Business, Computer Science, & Technology Entrepreneurship

Community Service in Action: Founder/Lead Designer of the MTEI Program

Research in Action: Helping Software Engineers and Industry do Privacy by Design

Advising European Privacy R&D and Industry Applications

Department of Finance, Information Systems, and Mgmt. Science
SOBEY SCHOOL OF BUSINESS
Saint Mary's University, Halifax, NS, B3H 3C3
Phone: 1 902 491 6441

Sobey School Bio
Website ; Twitter @DNJutla

CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited.

On Wed, Jun 18, 2014 at 11:00 AM, <frederick.hirsch@nokia.com> wrote:

I have some comments and questions on the latest draft based on a quick read, apologies if I’ve missed topics discussed elsewhere or in the other comments.

I’ve edited the attached draft with some minor editorial updates and some Word comments.

Overall I agree with Kim that it might be helpful to clearly delineate the core normative material from tutorial and explanatory material, either in one document or elsewhere. This should make it easier to review what is required for compliance. In some places I lower-cased non-RFC words in the attached draft, or removed upper case may where it was more the English usage.

I also believe it is important to be clear on the target audience, which appears to be ‘enterprise software development projects’ or system integrators.

The reason I mention this is that it might help to mention how this specification could fit with light-weight, lean, incremental projects not under the control of a single organization. I’m thinking of internet/web projects where a platform is created by one or more groups, and used by others to create a system. In this case, I would suggest that the platform team(s) should be aware of privacy concerns, but that the system integrator is responsible for the overall analysis as in this document (but may not be able to analyze or document the platform itself).
This case is difficult because the assumed organizational structure is not in place, nor is there full information for any party. I’d argue that this specification could then be used to measure the degree of compliance and then identify gaps, possibly enabling changes to achieve fuller compliance.

Based on this concern, I suggest changing the requirement for UX design to SHOULD ( SHOULD describe privacy UI/UX design ) since a platform developer could have no control over the UI, but maybe over other aspects.

Editorially, I suggest removing all placeholders and comments regarding future work from the document - this can go on the TC wiki roadmap, which would be more flexible, especially as plans could change.

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

pbd-se message