Privacy Req 5: Difference between revisions
Mary Hodder (talk | contribs) (added roles for phase II) |
m (15 revisions imported: Initial Upload of old pages from IDESG Wiki) |
||
(One intermediate revision by one other user not shown) | |||
Line 20: | Line 20: | ||
the application of limitations to, and scope of, individual transactions and data exchanges. | the application of limitations to, and scope of, individual transactions and data exchanges. | ||
See also | === Supplemental Information === | ||
Collection of personal information from repeated data transactions, which can be associated to form a larger body of knowledge about individuals, increases their privacy risk if the aggregated data exceeds the amount and nature needed for the original purposes of collection. | |||
=== References and Guidance (non-normative) === | |||
* PbD De-identification Center, https://www.privacybydesign.ca/index.php/de-identification-centre/ | |||
* See also the definition of "data aggregation" in § 164.501, and the discussions about the use of identified versus de-identified data in § 164.514(a),(b) and § 164.502(d), of the HIPAA regulations for health care transactions, 45 CFR Part 164: http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5 | |||
* See OASIS Privacy Management Reference Model (PMRM) v1.0: Section 4.2 ("Service Details"). | |||
=== REFERENCES === | === REFERENCES === |
Latest revision as of 04:03, 28 June 2018
<< Back to Baseline Functional Requirements Index
PRIVACY-5. DATA AGGREGATION RISK
Entities MUST assess the privacy risk of aggregating personal information, in systems and processes where it is collected, generated, used, transmitted, or stored, and wherever feasible, MUST design and operate their systems and processes to minimize that risk. Entities MUST assess and limit linkages of personal information across multiple transactions without the USER's explicit consent.
SUPPLEMENTAL GUIDANCE
Regarding "personal information", see Appendix A, and PRIVACY-1 (DATA MINIMIZATION).
Collection of personal information from repeated data transactions, which can be associated to form a larger body of knowledge about individuals, may increase their privacy risk. For example: An Identity Provider’s ability to facilitate transactions between a user and multiple relying parties may give the Identity Provider privileged insights into the users’ behavior. Such information is the result of the Identity Provider’s ability to link user interactions across transactions.
“Users’ explicit consent” alone should not be used to mitigate privacy risks created by technical architecture or design, such as to mitigate risks that individuals could not be reasonably expected to be able to assess.
See also Requirements PRIVACY-1 (DATA MINIMIZATION) and PRIVACY-2 (PURPOSE LIMITATION) on the application of limitations to, and scope of, individual transactions and data exchanges.
Supplemental Information
Collection of personal information from repeated data transactions, which can be associated to form a larger body of knowledge about individuals, increases their privacy risk if the aggregated data exceeds the amount and nature needed for the original purposes of collection.
References and Guidance (non-normative)
- PbD De-identification Center, https://www.privacybydesign.ca/index.php/de-identification-centre/
- See also the definition of "data aggregation" in § 164.501, and the discussions about the use of identified versus de-identified data in § 164.514(a),(b) and § 164.502(d), of the HIPAA regulations for health care transactions, 45 CFR Part 164: http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5
- See OASIS Privacy Management Reference Model (PMRM) v1.0: Section 4.2 ("Service Details").
REFERENCES
Further reference materials to aid organizations interested in conforming to these Requirements can be found at the wiki page Supplemental Privacy Guidance; this has been archived at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx
APPLIES TO ACTIVITIES
REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION
KEYWORDS
AGGREGATION, CONSENT, DESIGN, LIMITATION, PRIVACY, RISK
APPLIES TO ROLES
1 - RELYING PARTIES
2 - IDENTITY PROVIDERS
3 - Attribute Providers
4 – Intermediaries
5 - Credential Service Providers (where there is user interaction)
Quick Links: SALS | Baseline Functional Requirements v1.0 | Glossary |