RE: RFC 6973: Privacy Considerations for Internet Protocols

Hi Frank,

All good points, but I especially support your 3rd bullet ... on making Privacy Considerations coverage mandatory ... and would prefer the combined option ("Security and Privacy Considerations") to promote consolidation (where appropriate) of the Confidentiality leg of the security controls "CIA" triad with closely associated Privacy controls.  (This is something that, in my judgment, the recent and otherwise excellent rev 4 update of NIST's SP 800-53 (now with "Security and Privacy Controls" in the title did not get as right as it could have, since the Privacy controls are in a separate Appendix J).

Avanti,
BobN

From: Frank.Dawson@nokia.com [mailto:Frank.Dawson@nokia.com]
Sent: Wednesday, August 07, 2013 2:52 PM
To: joe@cdt.org; public-privacy@w3.org
Subject: RE: RFC 6973: Privacy Considerations for Internet Protocols

Hei Joseph.

Indeed, solid work. The document has improved quite a bit. The introduction has improved. Section 7 on mitigation/treatment approaches is good addition. Section 8 example is a thoughtful addition.

If it gets revised in the near future, maybe the following could be addressed as editorial comments.

- A number of the term definitions are circular (E.G., Anonymity:  The state of being anonymous).
- Some terms might need to be reset to their privacy context (E.G., Linkability, which I prefer the definition: " A measure of degree to which data elements are linkable to true name of the data subject, where unlinkability meant different records cannot be linked together and related to a specific personal identity").
- Privacy Considerations should be a MUST section in all specification, or merged with security in the "Security and Privacy Considerations" section. To make this optional leave room for discounting it from applicable specifications. Specification with negligible privacy impact can always declare it in that section. But making it optional leaves room for omission when it would be applicable.
- It is good that reference is made to privacy principles in the introduction, but if the threat analysis is not tied to what principle is being threatened then a less systematic and more ad hoc approach to determining privacy impact is taken. The threats and mitigations sections could be edited and re-structured to achieve this.
- In addition, threats can manifest around different vulnerabilities given which step in the privacy data life cycle it materializes in. The risk can also be different at different PDLC steps.
- Secondary Use as a privacy threat ought to be relabeled as either Unauthorized Use or Illegitimate Use because secondary purposes might be valid and authorized (E.G., fraud detection, service improvement).
- Similar comment about Disclosure. Unauthorized Disclosure would have been a better term.
- Exclusion is not generally used to describe the lack of "Individual Participation" (OECD and ISO 29100 principle) or "Access/Participation" (FIPP principle). Term or phrase that conveyed negative of these accepted principles (E.G., Denial of Access and Individual Participation) would better convey the principle that is being threatened.

Frank/