Julie,
I’d like to formally acknowledge receipt of your comments.
We have broken them out into a series of 24 distinct issues and the editors will be reviewing them in the coming days. We will come back to you with information on progress made and our recommendations.
I had a few problems with your line and page numbers – on some they could have just been slips of the finger in keying in the numbers, others are less clear.
I attach a copy of the spreadsheet that we will be using – maybe you could clarify the numbering against the published PDF
only (our stable reference point for all reviews) as published at
http://docs.oasis-open.org/pmrm/PMRM/v1.0/csprd02/PMRM-v1.0-csprd02.pdf
Many thanks once again for your painstaking review.
Best regards,
Peter Brown
PMRM Co-Editor
|
|
Peter F Brown Independent Consultant web: www.peterfbrown.com twitter: @pensivepeter |
P.O. Box 49719, Los Angeles, CA 90049, USA
Phone : (310) 694-2278
From:
Grady, Julie [mailto:julie.grady@hp.com]
Sent: Monday, 21 January, 2013 12:05
To: pmrm-comment@lists.oasis-open.org
Cc: Pearson, Siani; Grady, Julie
Subject: [pmrm-comment] PMRM-OASIS FEEDBACK Public Review
Please find attached the feedback from the ‘The Cloud Accountability Project – A4CLOUD’ – this is an EU Seventh Framework Programme Collaborative Research project involving thirteen partners from
across Europe. The 13 partners in the project are Hewlett Packard Laboratories, SAP Research, Cloud Security Alliance Europe, Athens Technology Centre, ARMINES, Eurecom, Hochschule Furtwangen University, Karlstads Universitet, Queen Mary University of London,
Stiftelsen SINTEF, Tilburg University, University of Stavanger, Universidad de Málaga.
There is a lot of value in proposing such a methodology, but it remains still at a very abstract level, making it difficult to assess the degree of compliance implemented privacy management services
eventually put in place by following the methodology. It would be necessary to determine a number of verifiable criteria those services need to follow in order to ensure their trustworthiness. These criteria are not given in the document. It is also uncertain
how practical this methodology is and how much the stakeholders would be willing to invest in it: integrating it with methodologies such as those being developed by CSA and/or extending existing security processes to include privacy assessment would make it
more likely to be adopted.
What is also missing is some guidance on how privacy preferences must represented, such that user consent and choices are unambiguously collected to allow for further automation and verification.
We propose that the authors include some additional tasks and services related to "detective" and "corrective" accountability services which have a direct link with privacy: for example, privacy violation reports,
facilitation of redress, risk mitigation, etc.
The reusability of the privacy management services are also questionable since each domain can implement alternative APIs for them, making the data usage control more difficult or incompatible
across multiple domains.
More specific comments relating to the latest changes follow:
Line 139, Page 6: It is said that users can adopt the model partially; is that being partially compliant? It would be important to understand the implications
for what level of compliance can be achieved according to the context and the parts of the model that were implemented.
Lines 31-35, Page 7: The definition of policy is very broad. While the definition itself seems reasonable, what is not so clear is how the proposed reference
architecture and methodology relates to all these different layers, and indeed the way in which these different types of policy are mapped across to each other. That is a very hard problem, and so this statement seems very broad and should perhaps be qualified
further with respect to the objectives of the proposed methodology itself. In fact, the methodology doesn’t provide an explanation for how this is done at all.
Line 35, Page 7: Personally identifiable information is mentioned but not defined or mentioned previously in the document, which seems odd – it would be
more natural to introduce that term earlier if it were to be used here.
Line 48, Page 8: It would be clearer if it could be summarized how the PMRM addresses these issues.
Line 50-51, Page 8: It is not clear that the statement ‘Because data can so easily migrate across jurisdictional boundaries, rights cannot be protected
without explicit specification of what boundaries apply.’ is true. For example, it could be read in the sense of physical/national boundaries needing to be specified in advance, but that isn’t necessarily the case if the processing environment can be guaranteed
to be a certain minimum standard (cf. Binding Corporate Rules, or other accountability-based approaches).
Line 191, Page 15: It is not clear how input from stakeholders not using the PMRM system (or for whom the information involved would be rather too complex)
is to be gathered, if at all. It is not clear what the different views on the system will be, and in what ways actors might be restricted in seeing information.
Lines 360-370, Page 18:
Regarding Task 8 on "Identifying Roles and Responsibilities within a Domain", this step seems to be too early in the process. Indeed, privacy controls (actions) are specified later in Task 15 and it would be more convenient to define responsibilities
with respect to each required privacy control. Maybe this task 8 can still remain as it is, with responsibilities defined at a high level, and be repeated after having defined the main privacy controls. Regarding the definition of privacy domains, authors
may wish to define some hierarchy with respect to domains so that some of the owners may inherent responsibilities from others that are at the higher level. Indeed, the second example provided in the beginning of page 18 mentions that "the physical location
is part of a larger logical privacy domain") which means that this domain may be owned by several owners.
Lines 371-383, Page 18: Task 9 on "identifying Touch points" is very interesting since these are the points data flows intersect. Unfortunately, it is not clear how privacy controls and responsibilities
will respectively be implemented and affected at these particular points.
Line 303, Page 19: Surely a large part of the analysis in section 3.1 should depend upon what type of service and deployment model the cloud service providers
offer, what their architectures and controls are, etc. See for example the analysis given in the recent CSA guidelines.
Line 409, Page 19: Typo “doman” should be “domain”.
Lines 347-357, Page 20: It is not clearly described what a privacy domain is.
Lines 519-520, Page 22: Recommend assigning a number to the table.
Line 446, Page 23: Mentions “reasonable assurance”. An example is the generation of logs regarding the accomplishment of obligations, for which no further
guidance about what to log and how to preserve it are given.
Lines 546-562, Pages 23-24: The first intends to validate the accuracy, completeness, etc of the PI only. I would expect to have a orthogonal process to
validate the services themselves in terms of their accountability. The same happens to the certification service that is basically some identity checks on who is processing the data, which is essential but not sufficient.
Section 4.1, Page 25: Regarding privacy services, the usage service includes the access service defined under "Presentation and Lifecycle services" since from the definition of an access service
given in page 24, this service includes the possibility for data subjects for changes in PIs. It was difficult to understand the importance of this service and unfortunately the further examples do not illustrate the need for such a service (although usage
is included).
Page 28: The security service has the requirements to secure PI, but there is no recommendation about the protection/trustworthiness about of evidence generated
by the other services to attest the correct data handling.
Page 35: Many of the definitions in the operational FIPPs have been changed to be incorrect; the wording should be changed back to be in accordance with
FIP definitions and the way that these terms are used in legal and policy circles; further details are given below
Line 731, Page 35: The definition of accountability is incorrect. First of all, the definition of accountability based upon FIP is quite narrow in scope,
and this term has evolved to have a different meaning amongst policy makers forty years later. Secondly, the definition from FIP has been altered via the latest changes to actually be incorrect – it was the data controller (that might be an individual or entity)
being referred to that should be made accountable, not the data subject as stated here.
Line 736-7, Page 35: It is not clear that the changes to the definition made here are valid: notice has a specific meaning in terms of the data controller
providing notice about its handling of personal information that it is collecting to data subjects and not the definition given here, which is changed to be something different and much broader
Line 749, Page 35: This definition has been changed to be incorrect – it is not just the processor that is involved here, it is the data controller
Kind Regards,
Julie
Julie Grady
Project Manager A4Cloud
julie.grady@hp.com
T +44(0)117 316 2797
HP Labs
Long Down Avenue
Stoke Gifford
BS34 8QZ
Print with the environment in mind