comment from Kimberly 2014-09-01
Source: In the Privacy Framework, regarding "Organizations will request individuals’ credentials only when necessary for the transaction and then only as appropriate to the risk associated with the transaction or only as appropriate to the risks to the parties associated with the transaction."
Suggestion: Change the word "request" to "obtain".
Rationale: "Request" presumes all technologies added to a community are incapable of just taking, replicating, and/or reusing active or stored credentials of others in large masses. For example, replicating and controlling personal address books to inappropriate locations (such as employer address books) as a "community service". Whether a combination of new technology usage was done intentionally or unintentionally that abused an individual's authorization credentials, the result is the same: personal data was taken without authorization (which cannot be easily removed by the private individual as data owner).
Additional comment by tomj
Actually organizations should be discouraged from obtaining user's credentials in any case, that basically implies that a password is sent by the user or user's agent. It is far preferable that the user only prove possession of the credential, as would be the case if the cred were contained in some sort of cryptographic token.
Proposed high-level requirement addition by Ann Racuya-Robbins
“Users' shall(should) have a well-defined set of recorded natural language opportunities to document and express his or her requirements and the parameters of those requirements before interacting with Service Providers in online transactions.”
comments from --Jerry Kickenson (talk) 22:16, 14 February 2015 (UTC)
- Generally, these requirements are very high level and vague, using terms such as "necessary", "specified purposes", "minimize", "easy-to-understand", "appropriate" and "effective" with no definition or clarification. I see that these are indeed meant to be "High-level requirements that are guiding functional requirements development. " The Functional Privacy Requirements Development spreadsheet is a start, but even there I don't (yet) see much additional guidance.
- There is a requirement for informing end users, but none for obtaining end user consent for any use of their data. Consent and control are core requirements in privacy certification schemes such as Privacy Trust and TrustE.
- Most of these requirements refer to "organizations", which seem mostly to be relying parties providing services to end users using credentials provided by others. There could be requirements specific to the identity ecosystem, on identity and attribute providers. For instance, the requirement "Organizations shall minimize data aggregation, including linkages across transactions." might be to prohibit this for identity and attribute providers or, if not so strict, requiring consent from end users for identity and attribute providers to store or use such end user activity data (is that included in "personal" data?).
- It would help to number these high level requirements on the wiki to match the numbers assigned in the Core Operations Privacy Requirements Development spreadsheet.