IDESG Wiki - User contributions [en]

Privacy Req 1

2018-06-20T20:12:26Z

Mary Hodder: /* REFERENCES */ fixed text explanation

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-1. DATA MINIMIZATION ==
Entities MUST limit the collection, use, transmission and storage of [[IDEF Glossary PERSONAL INFORMATION|personal information]] to the minimum necessary to fulfill that transaction’s purpose and related legal requirements. Entities providing claims or attributes MUST NOT provide any more personal information than what is requested. Where feasible, [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY-PROVIDERS]] MUST provide technical mechanisms to accommodate information requests of variable granularity, to support data minimization.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]].

This requirement limiting the collection, use and storage will apply to every transaction where user private information is exchanged. [Entities are encouraged to address this issue by design, before run time, by limiting or applying controls or filters to classes of data.]

This requirement limiting the provisioning of personal information applies to the entire lifetime of data on the entity’s site.

The boundaries of a TRANSACTION between an entity and a user are defined during the interchange where the user is identified to the entity (for example from signin to signout of the user.) See [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]].

=== Supplemental Information ===

IDENTITY PROVIDERS and RELYING PARTIES which employ intermediaries are responsible for the actions of those intermediaries on their behalf, MUST implement protocols that mitigate the risk of intermediaries collecting personal information. See [[Interop_Req_8|INTEROP-8]] and [[Interop_Best_Practice_E|INTEROP-BP-E]].

=== REFERENCES ===
References and Guidance (non-normative)

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.5 ("Data minimization").
* See the HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): "minimum necessary" disclosure standard.
* See AICPA/CICA Privacy Maturity Model based on GAPP [Collection 4.1.X] (chart)
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46], Audit [p47].

Further reference materials to aid organizations interested in conforming to these Requirements can be found at the wiki page [[Privacy References and Guides]]; this page is a living document from the Privacy Committee, and as such will be added to over time. It has been archived at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== APPLIES TO ROLES ===
Relying Parties, Identity Providers, Attribute Providers, Intermediaries, Credential Service Providers (where there is user interaction) 

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 1

2018-06-20T20:11:00Z

Mary Hodder: /* REFERENCES */ updated page name

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-1. DATA MINIMIZATION ==
Entities MUST limit the collection, use, transmission and storage of [[IDEF Glossary PERSONAL INFORMATION|personal information]] to the minimum necessary to fulfill that transaction’s purpose and related legal requirements. Entities providing claims or attributes MUST NOT provide any more personal information than what is requested. Where feasible, [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY-PROVIDERS]] MUST provide technical mechanisms to accommodate information requests of variable granularity, to support data minimization.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]].

This requirement limiting the collection, use and storage will apply to every transaction where user private information is exchanged. [Entities are encouraged to address this issue by design, before run time, by limiting or applying controls or filters to classes of data.]

This requirement limiting the provisioning of personal information applies to the entire lifetime of data on the entity’s site.

The boundaries of a TRANSACTION between an entity and a user are defined during the interchange where the user is identified to the entity (for example from signin to signout of the user.) See [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]].

=== Supplemental Information ===

IDENTITY PROVIDERS and RELYING PARTIES which employ intermediaries are responsible for the actions of those intermediaries on their behalf, MUST implement protocols that mitigate the risk of intermediaries collecting personal information. See [[Interop_Req_8|INTEROP-8]] and [[Interop_Best_Practice_E|INTEROP-BP-E]].

=== REFERENCES ===
References and Guidance (non-normative)

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.5 ("Data minimization").
* See the HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): "minimum necessary" disclosure standard.
* See AICPA/CICA Privacy Maturity Model based on GAPP [Collection 4.1.X] (chart)
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46], Audit [p47].

Further reference materials to aid organizations interested in conforming to these Requirements can be found at the wiki page [[Privacy References and Guides]]; this has been archived at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== APPLIES TO ROLES ===
Relying Parties, Identity Providers, Attribute Providers, Intermediaries, Credential Service Providers (where there is user interaction) 

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 5

2018-06-18T22:00:00Z

Mary Hodder: added info from linked SG page

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-5. DATA AGGREGATION RISK ==
Entities MUST assess the privacy risk of aggregating [[IDEF Glossary PERSONAL INFORMATION|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 [[IDEF Glossary USERS|USER]]'s explicit consent.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|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 Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and [[Privacy Req 2|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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords AGGREGATION|AGGREGATION]], [[IDEF Keywords CONSENT|CONSENT]], [[IDEF Keywords DESIGN|DESIGN]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords RISK|RISK]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 4

2018-06-18T21:58:47Z

Mary Hodder: added info from linked SG page

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-4. CREDENTIAL LIMITATION ==
Entities MUST NOT request [[IDEF Glossary USERS|USERS]]’ credentials unless necessary for the transaction and then only as appropriate to the risk associated with the transaction or to the risks to the parties associated with the transaction.

=== SUPPLEMENTAL GUIDANCE ===
Intermediaries may not have a direct relationship with individuals whose data moves through their systems,
but should facilitate endpoints' ability to conform to this Requirement.

See the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model] for definition of Transaction Intermediation for the scope of “intermediaries.” The functional model describes Transaction Intermediation as “Processes and
procedures that limit linkages between transactions and facilitate credential portability." This includes
functions defined as “Blinding,” “Psuedonymization/Anonymization,” and “Exchange.”

See Requirements [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]] on the application of limitations to, and scope of, individual transactions and data exchanges.

=== Supplemental Information ===

Credentials bound to identifiers, like attributes bound to identifiers, carry increased risk of inappropriate disclosure when stored. See generally [[Privacy_Req_1|PRIVACY-1]]. This requirement PRIVACY-4 assumes that the privacy risk analysis required by [[Privacy_Req_5|PRIVACY-5]] will inform an entity's decisions about credential retention.

=== References and Guidance (non-normative) ===

See [[Privacy_Req_2|PRIVACY-2]] and [[Privacy_Req_3|PRIVACY-3]].

=== 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 ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords CREDENTIAL|CREDENTIAL]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords LIMITATION|LIMITATION]],
[[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]], [[IDEF Keywords RISK|RISK]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 3

2018-06-18T21:57:20Z

Mary Hodder: added info from linked page for SG

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-3. ATTRIBUTE MINIMIZATION ==
Entities requesting [[IDEF Glossary ATTRIBUTES|attributes]] MUST evaluate the need to collect specific attributes in a transaction, as opposed to claims regarding those attributes. Wherever feasible, entities MUST collect, generate, use, transmit, and store claims about [[IDEF Glossary USERS|USERS]] rather than attributes. Wherever feasible, attributes MUST be transmitted as claims, and transmitted credentials and identities MUST be bound to claims instead of actual attribute values.

=== SUPPLEMENTAL GUIDANCE ===
Where feasible, Identity Providers (and any other entities releasing attributes) should provide the
opportunity for attributes to be released as claims as well as detailed attributes; see also [[Privacy Req 1|PRIVACY-1
(DATA MINIMIZATION)]] on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own legal or business processes to collect and store, although
not necessarily transmit, attributes in their attribute form, in which case significant alteration or
filtering may be required when that data is re-used or transmitted to others.

For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.

=== Supplemental Information ===

IDENTITY-PROVIDERS (and any other entities releasing attributes MUST provide the opportunity for attributes to be released as claims as well as detailed attributes; see also [[Privacy_Req_1|PRIVACY-1]] on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own business processes to collect and store, although not necessarily transmit, attributes in their attribute form, in which case significant alteration or filtering may be required when that data is re-used or transmitted to others.

=== References and Guidance (non-normative) ===

* NIST SP 800-162: Attribute Based Access Control Definition and Considerations (2014), pages 26, 28, 31: http://csrc.nist.gov/publications/nistpubs/800-162/sp800_162_pre-publication.pdf

=== 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 ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ATTRIBUTES|ATTRIBUTE]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 2

2018-06-18T18:00:22Z

Mary Hodder: syntax

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-2. PURPOSE LIMITATION ==
Entities MUST limit the use of [[IDEF Glossary PERSONAL INFORMATION|personal information]] that is collected, used, transmitted, or stored to the specified purposes of that transaction. Persistent records of contracts, assurances, consent, or legal authority MUST be established by entities collecting, generating, using, transmitting, or storing personal information, so that the information consistently is used in the same manner originally specified and permitted.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]]. Entities should also assure that their data
controls reliably apply these limitations to their future actions.

See also Requirement [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] on the application of limitations to, and
scope of, individual transactions and data exchanges.

Please note the applicability of best practice [[Interop Best Practice G|INTEROP-BP-G (RECOMMENDED LEGAL COMPLIANCE)]]
regarding limitations imposed by laws. Please note the applicability of best practice [[Interop Best Practice F|INTEROP-BP-F
(RECOMMENDED FEDERATION COMPLIANCE)]] and Requirement [[Interop Req 6|INTEROP-6 (THIRD-PARTY
COMPLIANCE)]] regarding limitations arising from the involvement of THIRD-PARTIES such as
intermediaries, similar service providers, or FEDERATIONS.

See the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model] for definition of Transaction Intermediation for the scope of
“intermediaries.” The functional model describes Transaction Intermediation as “Processes and
procedures that limit linkages between transactions and facilitate credential portability. This includes
functions defined as “Blinding,” “Pseudonymization/Anonymization,” and “Exchange.”

=== Supplemental Information ===

Contracts, assurances or persistent records of consent or legal authority MUST be established by entities collecting, using, transmitting or storing personal information, so that the information, when passed between entities, is still used in the same manner as originally specified and permitted. Entities also must assure that their data controls reliably apply these limitations to their future actions.

Please note the applicability of requirement [[Interop_Req_7|INTEROP-7]] regarding limitations imposed by laws. Please note the applicability of requirements [[Interop_Req_6|INTEROP-6]] and [[Interop_Req_8|INTEROP-8]] regarding limitations arising from the involvement of THIRD-PARTIES such as intermediaries, similar service providers, or FEDERATIONS.

=== References and Guidance (non-normative) ===

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.3 ("Use, Retention and Disclosure Limitation") and Section 5.6 ("Purpose Legitimacy and Specification").
* See the "minimum necessary" disclosure standard in HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5
* See also the Fair Information Privacy Principles: "Organizations should use PII solely for the purpose(s) specified in the notice. Sharing PII should be for a purpose compatible with the purpose for which the PII was collected." http://www.nist.gov/nstic/NSTIC-FIPPs.pdf
* See OASIS Privacy Management Reference Model (PMRM) v1.0: Section 4.2 ("Service Details").
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46],Audit [p47], and Storage [p47].

=== 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 ROLES ===
[[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
[[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
Attribute Providers 
Intermediaries 
Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 2

2018-06-18T17:58:48Z

Mary Hodder: added appendix A supplemental information

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-2. PURPOSE LIMITATION ==
Entities MUST limit the use of [[IDEF Glossary PERSONAL INFORMATION|personal information]] that is collected, used, transmitted, or stored to the specified purposes of that transaction. Persistent records of contracts, assurances, consent, or legal authority MUST be established by entities collecting, generating, using, transmitting, or storing personal information, so that the information consistently is used in the same manner originally specified and permitted.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]]. Entities should also assure that their data
controls reliably apply these limitations to their future actions.

See also Requirement [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] on the application of limitations to, and
scope of, individual transactions and data exchanges.

Please note the applicability of best practice [[Interop Best Practice G|INTEROP-BP-G (RECOMMENDED LEGAL COMPLIANCE)]]
regarding limitations imposed by laws. Please note the applicability of best practice [[Interop Best Practice F|INTEROP-BP-F
(RECOMMENDED FEDERATION COMPLIANCE)]] and Requirement [[Interop Req 6|INTEROP-6 (THIRD-PARTY
COMPLIANCE)]] regarding limitations arising from the involvement of THIRD-PARTIES such as
intermediaries, similar service providers, or FEDERATIONS.

See the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model] for definition of Transaction Intermediation for the scope of
“intermediaries.” The functional model describes Transaction Intermediation as “Processes and
procedures that limit linkages between transactions and facilitate credential portability. This includes
functions defined as “Blinding,” “Pseudonymization/Anonymization,” and “Exchange.”

'''Supplemental Guidance''' 
These links are provided as additional informative resources relevant to parties conducting self-assessments (and other identity stakeholders) when applying and evaluating IDEF Baseline Requirement PRIVACY-2.

=== Supplemental Information ===

Contracts, assurances or persistent records of consent or legal authority MUST be established by entities collecting, using, transmitting or storing personal information, so that the information, when passed between entities, is still used in the same manner as originally specified and permitted. Entities also must assure that their data controls reliably apply these limitations to their future actions.

Please note the applicability of requirement [[Interop_Req_7|INTEROP-7]] regarding limitations imposed by laws. Please note the applicability of requirements [[Interop_Req_6|INTEROP-6]] and [[Interop_Req_8|INTEROP-8]] regarding limitations arising from the involvement of THIRD-PARTIES such as intermediaries, similar service providers, or FEDERATIONS.

=== References and Guidance (non-normative) ===

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.3 ("Use, Retention and Disclosure Limitation") and Section 5.6 ("Purpose Legitimacy and Specification").
* See the "minimum necessary" disclosure standard in HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5
* See also the Fair Information Privacy Principles: "Organizations should use PII solely for the purpose(s) specified in the notice. Sharing PII should be for a purpose compatible with the purpose for which the PII was collected." http://www.nist.gov/nstic/NSTIC-FIPPs.pdf
* See OASIS Privacy Management Reference Model (PMRM) v1.0: Section 4.2 ("Service Details").
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46],Audit [p47], and Storage [p47].

=== 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 ROLES ===
[[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
[[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
Attribute Providers 
Intermediaries 
Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 1

2018-06-18T17:51:04Z

Mary Hodder: syntax update

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-1. DATA MINIMIZATION ==
Entities MUST limit the collection, use, transmission and storage of [[IDEF Glossary PERSONAL INFORMATION|personal information]] to the minimum necessary to fulfill that transaction’s purpose and related legal requirements. Entities providing claims or attributes MUST NOT provide any more personal information than what is requested. Where feasible, [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY-PROVIDERS]] MUST provide technical mechanisms to accommodate information requests of variable granularity, to support data minimization.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]].

This requirement limiting the collection, use and storage will apply to every transaction where user private information is exchanged. [Entities are encouraged to address this issue by design, before run time, by limiting or applying controls or filters to classes of data.]

This requirement limiting the provisioning of personal information applies to the entire lifetime of data on the entity’s site.

The boundaries of a TRANSACTION between an entity and a user are defined during the interchange where the user is identified to the entity (for example from signin to signout of the user.) See [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]].

=== Supplemental Information ===

IDENTITY PROVIDERS and RELYING PARTIES which employ intermediaries are responsible for the actions of those intermediaries on their behalf, MUST implement protocols that mitigate the risk of intermediaries collecting personal information. See [[Interop_Req_8|INTEROP-8]] and [[Interop_Best_Practice_E|INTEROP-BP-E]].

=== REFERENCES ===
References and Guidance (non-normative)

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.5 ("Data minimization").
* See the HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): "minimum necessary" disclosure standard.
* See AICPA/CICA Privacy Maturity Model based on GAPP [Collection 4.1.X] (chart)
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46], Audit [p47].

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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== APPLIES TO ROLES ===
Relying Parties, Identity Providers, Attribute Providers, Intermediaries, Credential Service Providers (where there is user interaction) 

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 1

2018-06-18T17:30:58Z

Mary Hodder: added Supplemental info from the other appendix A SG

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-1. DATA MINIMIZATION ==
Entities MUST limit the collection, use, transmission and storage of [[IDEF Glossary PERSONAL INFORMATION|personal information]] to the minimum necessary to fulfill that transaction’s purpose and related legal requirements. Entities providing claims or attributes MUST NOT provide any more personal information than what is requested. Where feasible, [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY-PROVIDERS]] MUST provide technical mechanisms to accommodate information requests of variable granularity, to support data minimization.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]].

This requirement limiting the collection, use and storage will apply to every transaction where user private information is exchanged. [Entities are encouraged to address this issue by design, before run time, by limiting or applying controls or filters to classes of data.]

This requirement limiting the provisioning of personal information applies to the entire lifetime of data on the entity’s site.

The boundaries of a TRANSACTION between an entity and a user are defined during the interchange where the user is identified to the entity (for example from signin to signout of the user.) See [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]].

=== Supplemental Information ===

IDENTITY PROVIDERS and RELYING PARTIES which employ intermediaries are responsible for the actions of those intermediaries on their behalf, MUST implement protocols that mitigate the risk of intermediaries collecting personal information. See [[Interop_Req_8|INTEROP-8]] and [[Interop_Best_Practice_E|INTEROP-BP-E]].

=== REFERENCES ===
References and Guidance (non-normative)

* See ISO/IEC 29100 (2011) Privacy Framework, Section 5.5 ("Data minimization").
* See the HIPAA regulations for health care transactions, 45 CFR Part 164, at §§ 164.502(b) and 164.514(d): "minimum necessary" disclosure standard.
* See AICPA/CICA Privacy Maturity Model based on GAPP [Collection 4.1.X] (chart)
* See Privacy & Biometrics: Building a Conceptual Foundation: Data [p46], Audit [p47].

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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== APPLIES TO ROLES ===
1 - Relying Parties 
2 - Identity Providers 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Best Practice C

2018-06-13T21:00:58Z

Mary Hodder: updated roles for Phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-BP-C. RECOMMENDED CONSEQUENCES OF DECLINING ==
Entities SHOULD provide short, clear notice to [[IDEF Glossary USERS|USERS]] of the consequences of declining to provide mandatory and optional [[IDEF Glossary PERSONAL INFORMATION|personal information]].

=== SUPPLEMENTAL GUIDANCE ===
This recommendation builds on and improves the mandate in Requirement [[Privacy Req 11|PRIVACY-11 (OPTIONAL
INFORMATION)]].

Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]] and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]]. See also
the [[Baseline_Functional_Requirements_v1.0#Usability|IDESG Usability Requirements]] (USABLE-1 through USABLE-7) regarding the clarity of notices given
to [[IDEF Glossary USERS|USERS]] and others.

If personal information is requested from USERS during registration that is optional, that designation
should include a short and clear description justifying the request of that data.

If information collection or attribute value release is designated as mandatory, that designation
should include a short and clear description of the consequences of declining to provide that
information or allowing that release.

If an entity requests to release attributes values during a transaction that are the beyond the
minimum necessary to complete that transaction, that release should be clearly presented as
optional/a choice. That optional designation should include a short and clear description justifying the
release of that data.

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]],
[[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]]

=== KEYWORDS ===
[[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords NOTICE|NOTICE]], [[IDEF Keywords USABILITY|USABILITY]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
4 – Intermediaries 

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Best Practice B

2018-06-13T21:00:26Z

Mary Hodder: updated roles edit

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-BP-B. RECOMMENDED TECHNOLOGY ENFORCEMENT ==
Wherever feasible, privacy requirements and policies SHOULD be implemented through technical mechanisms. Those technical privacy controls SHOULD be situated as low in the technology stack as possible.

=== SUPPLEMENTAL GUIDANCE ===
Privacy controls are mechanisms that mitigate privacy risk. These may overlap with security controls.

=== REFERENCES ===
Further reference materials to aid organizations interested in conforming to these Requirements or best practices can be found at the wiki page [[Supplemental Privacy Guidance]]; this has been archived as of October 2015 at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx.

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]],
[[IDEF Functional Model CREDENTIALING|CREDENTIALING]],
[[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]],
[[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]],
[[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ARCHITECTURE|ARCHITECTURE]], [[IDEF Keywords POLICIES|POLICIES]], [[IDEF Keywords PROCESS|PROCESS]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Best Practice B

2018-06-13T20:59:56Z

Mary Hodder: updated roles for Phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-BP-B. RECOMMENDED TECHNOLOGY ENFORCEMENT ==
Wherever feasible, privacy requirements and policies SHOULD be implemented through technical mechanisms. Those technical privacy controls SHOULD be situated as low in the technology stack as possible.

=== SUPPLEMENTAL GUIDANCE ===
Privacy controls are mechanisms that mitigate privacy risk. These may overlap with security controls.

=== REFERENCES ===
Further reference materials to aid organizations interested in conforming to these Requirements or best practices can be found at the wiki page [[Supplemental Privacy Guidance]]; this has been archived as of October 2015 at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx.

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]],
[[IDEF Functional Model CREDENTIALING|CREDENTIALING]],
[[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]],
[[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]],
[[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ARCHITECTURE|ARCHITECTURE]], [[IDEF Keywords POLICIES|POLICIES]], [[IDEF Keywords PROCESS|PROCESS]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
4 – Intermediaries 

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Best Practice A

2018-06-13T20:59:15Z

Mary Hodder: updated roles for Phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-BP-A. RECOMMENDED QUALITY CONTROLS ==
Entities SHOULD determine the necessary quality of [[IDEF Glossary PERSONAL INFORMATION|personal information]] used in their [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS|digital identity management functions]] based on the risk of those functions and the information, including risk to the [[IDEF Glossary USERS|USERS]] involved.

=== SUPPLEMENTAL GUIDANCE ===
Entities obtaining personal information about a [[IDEF Glossary USERS|USER]] may have multiple ways to obtain the
necessary data, or to assure its quality (generally, its accuracy, detail, timeliness or authoritative
source). Some of those choices may be less invasive, or create less risk of USER privacy loss, than
others. Additionally, some may result in higher- or lower-quality accuracy of the data. Entities SHOULD
consider the effects of these choices on the USER whose personal information is being collected and
used.

In the absence of formal data quality standards, entities SHOULD consider the timeliness,
completeness, accuracy, and sources of data when evaluating the quality of personal information.
These goals may be most easily implemented in system design, when identity management systems are
being designed or renovated.

Regarding "personal information," see [[APPENDIX_A-Defined_Terms|Appendix A]] and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

=== REFERENCES ===
Further reference materials to aid organizations interested in conforming to these Requirements or best practices can be found at the wiki page [[Supplemental Privacy Guidance]]; this has been archived as of October 2015 at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]],
[[IDEF Functional Model CREDENTIALING|CREDENTIALING]],
[[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]],
[[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]],
[[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ARCHITECTURE|ARCHITECTURE]], [[IDEF Keywords DATA-INTEGRITY|DATA-INTEGRITY]], [[IDEF Keywords LIMITATION|LIMITATION]],
[[IDEF Keywords RISK|RISK]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 15

2018-06-13T20:56:57Z

Mary Hodder: updated SG and roles for Phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-15. ATTRIBUTE SEGREGATION ==
Wherever feasible, identifier data MUST be segregated from [[IDEF Glossary ATTRIBUTES|attribute]] data.

=== SUPPLEMENTAL GUIDANCE ===

User attributes can be used to narrow the pool of potential real world human beings to the point where the real world identity can be determined. That said, there are a set of user static identifiers which must be protected from disclosure above more general user information. An example of the identifiers that need special protection include:

1. Legal Name 
2. Social Security Number 
3. Street address of domicile 
4. Cell phone number 
5. Email address 

When recent identity protocols (like OpenID Connect) are used, it is technically possible to authenticate a user with no user identifiers or attributes at all. In that case the user identifiers in the protocol between digital entities should be opaque to the extent that any party outside of the Identity Provider and the Relying party will not be able to use those identifiers in any other context. In that case other baseline requirements will apply.

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]]

=== KEYWORDS ===
[[IDEF Keywords ARCHITECTURE|ARCHITECTURE]], [[IDEF Glossary ATTRIBUTES|ATTRIBUTE]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PROCESS|PROCESS]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
4 – Intermediaries 

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 14

2018-06-13T20:54:24Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-14. DATA RETENTION AND DISPOSAL==
Entities MUST limit the retention of [[IDEF Glossary PERSONAL INFORMATION|personal information]] to the time necessary for providing and administering the functions and services to [[IDEF Glossary USERS|USERS]] for which the information was collected, except as otherwise required by law or regulation. When no longer needed, personal information MUST be
securely disposed of in a manner aligning with appropriate industry standards and/or legal
requirements.

=== SUPPLEMENTAL GUIDANCE ===
Retention requirements arising from "law, regulation or legal process" may include litigation-related
legal holds, and requirements arising from mandatory audits.

Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

“Functions” refer to the functions listed in the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model]; see supplemental guidance
in [[Privacy Req 13|PRIVACY-13 (CONTROLS PROPORTIONATE TO RISK)]].

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]], [[IDEF Keywords RETENTION|RETENTION]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 13

2018-06-13T20:53:51Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-13. CONTROLS PROPORTIONATE TO RISK ==
Controls on the processing or use of [[IDEF Glossary USERS|USERS]]' [[IDEF Glossary PERSONAL INFORMATION|personal information]] MUST be commensurate with the degree of risk of that processing or use. A privacy risk analysis MUST be conducted by entities who conduct [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS|digital identity management functions]], to establish what risks those functions pose to users' privacy.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

Many risk analysis models include examples or guidance about the implementation of controls that
are appropriate to either specific risks or levels of existing risk. Entities may satisfy this Requirement by
confirming that they have conducted that risk assessment and, based on that assessment, made
appropriate adjustments to their practices.

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ASSESSMENT|ASSESSMENT]], [[IDEF Keywords CONTROL|CONTROLS]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords POLICIES|POLICIES]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords RISK|RISK]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 12

2018-06-13T20:52:36Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-12. ANONYMITY ==
Wherever feasible, entities MUST utilize identity systems and processes that enable transactions that are anonymous, anonymous with validated [[IDEF Glossary ATTRIBUTES|attributes]], pseudonymous, or where appropriate, uniquely identified. Where applicable to such transactions, entities employing service providers or intermediaries MUST mitigate the risk of those [[IDEF Glossary THIRD PARTIES|THIRD-PARTIES]] collecting [[IDEF Glossary USERS|USER]] [[IDEF Glossary PERSONAL INFORMATION|personal information]]. Organizations MUST 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.

=== SUPPLEMENTAL GUIDANCE ===
In support of legal, policy or personal requirements for anonymous or pseudonymous USER
participation, [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS|digital identity management functions]] and systems should permit anonymous and
(persistent across sessions) pseudonymous registration and participation, where required by law or
otherwise feasible. To further facilitate that goal, identifiers and personal data (including attributes)
should be kept separate wherever feasible: see [[Privacy Req 4|PRIVACY-4 (CREDENTIAL LIMITATION)]] and [[Privacy Req 15|PRIVACY-15 (ATTRIBUTE SEGREGATION)]].

Risk needs to be assigned by each entity based the risk of loss to assets or reputation of that entity.

See [[Interop Req 6|INTEROP-6 (THIRD-PARTY COMPLIANCE)]] on the mitigation of risks associated with third-party
service providers or data users.

See [[Privacy Req 5|PRIVACY-5 (DATA AGGREGATION RISK)]] regarding the risk of collecting additional information.

See [[Privacy Req 13|PRIVACY-13 (CONTROLS PROPORTIONATE TO RISK)]] regarding the implementation of controls to
mitigate identified privacy risk.

See [[Privacy Req 11|PRIVACY-11 (OPTIONAL INFORMATION)]] regarding availability of user choices regarding optional
disclosure of personal information.

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ACCOUNT|ACCOUNT]], [[IDEF Keywords ANONYMITY|ANONYMITY]], [[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords PRIVACY|PRIVACY]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 11

2018-06-13T20:48:45Z

Mary Hodder: updated roles

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-11. OPTIONAL INFORMATION ==
Entities MUST clearly indicate to [[IDEF Glossary USERS|USERS]] what [[IDEF Glossary PERSONAL INFORMATION|personal information]] is mandatory and what information is optional prior to the transaction.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

See also the [[Baseline_Functional_Requirements_v1.0#Usability|IDESG Usability Requirements]] (USABLE-1 through USABLE-7) regarding the clarity of
notices given to USERS and others.

Additional best practices for indicating optionality are provided in [[Privacy Best Practice C|PRIVACY-BP-C (RECOMMENDED
CONSEQUENCES OF DECLINING)]].

It may be appropriate to have a "don't ask me again" check box for a series of transactions of the
same type.

For example: If personal information is requested from USERS during registration that is beyond the
minimum necessary to complete an eligibility decision, that personal information should be clearly
marked as optional.

Regarding "mandatory" and "optional", in this Requirement, if personal information is requested
from USERS during registration that is beyond the minimum necessary to complete an eligibility
decision, that personal information should be clearly marked as optional. That optional designation
should include a short and clear description justifying the request of that data.

If an organization requests to release attributes values during a transaction that are the beyond the
minimum necessary to complete that transaction, that release should be clearly presented as
optional/a choice. That optional designation should include a short and clear description justifying the
release of that data.

If information or attribute value release is designated as mandatory, that designation should include
a short and clear description of the consequences of declining to provide that information or allowing
that release. See [[Privacy Req 10|PRIVACY-10 (USER OPTION TO DECLINE)]].

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]]

=== KEYWORDS ===
[[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords NOTICE|NOTICE]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
4 – Intermediaries 

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 10

2018-06-13T20:45:46Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-10. USER OPTION TO DECLINE ==
[[IDEF Glossary USERS|USERS]] MUST have the opportunity to decline registration; decline [[IDEF Glossary CREDENTIALS|credential]] provisioning; decline the presentation of their credentials; and decline release of their [[IDEF Glossary ATTRIBUTES|attributes]] or claims.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

Although an entity's [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS|digital identity management functions]] and transactions should provide an
opportunity to the USER to decline to provide personal information or consent to its use, that decision
may appropriately result in the partial or complete failure of the entity's intended transaction. (See
[[Usable Req 4|USABLE-4 (NAVIGATION)]], [[Usable Req 5|USABLE-5 (ACCESSIBILITY)]] and [[Usable Req 6|USABLE-6 (USABILITY FEEDBACK)]].)

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]]

=== KEYWORDS ===
[[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords CONSENT|CONSENT]], [[IDEF Keywords PRIVACY|PRIVACY]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 9

2018-06-13T20:44:57Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-9. USER NOTICE OF CHANGES ==
Entities MUST, upon any material changes to a service or process that affects the prior or ongoing collection, generation, use, transmission, or storage of [[IDEF Glossary USERS|USERS]]’
[[IDEF Glossary PERSONAL INFORMATION|personal information]], notify those USERS, and provide them with compensating controls designed to mitigate privacy risks that may arise from those changes, which may include seeking express affirmative consent of USERS in accordance with relevant law or regulation.

=== SUPPLEMENTAL GUIDANCE ===
Once USERS have been notified of the planned uses and processing of their personal information
(see [[Privacy Req 6|PRIVACY 6 (USAGE NOTICE)]]), and exercised whatever consent, limitation or withdrawal rights they
have (see [[Privacy Req 7|PRIVACY-7 (USER DATA CONTROL)]]), material changes to those uses or processing may render
their choices obsolete, so entities should refresh the USER's opportunity to exercise those controls in
light of the new information. (See [[Usable Req 4|USABLE-4 (NAVIGATION)]], [[Usable Req 5|USABLE-5 (ACCESSIBILITY)]] and [[Usable Req 6|USABLE-6
(USABILITY FEEDBACK)]].)

Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

“Express affirmative consent” should not be used to mitigate privacy risks created by technical
architecture or design, or to mitigate risks that individuals could not be reasonably expected to be able
to assess; see [[Privacy Req 5|PRIVACY-5 (DATA AGGREGATION RISK)]].

“Compensating controls” are controls or mechanisms, which may operate either by policy or
(preferably) technology, designed to mitigate privacy risks that may arise when a material change is
made to the system. Examples might include an opportunity to assent or withdraw, or risk-shifting
rules occurring upon a change. Those controls can be under user administration, but only if the user
can be reasonably expected to understand how to use those mechanisms to effectively mitigate their
risk.

The Kantara Consent Receipt is now available (January 2018) in draft form at https://groups.google.com/forum/#!topic/wg-infosharing/553qIdgaq0o

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords CHANGES|CHANGES]], [[IDEF Keywords CONSENT|CONSENT]], [[IDEF Keywords NOTICE|NOTICE]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 8

2018-06-13T20:43:55Z

Mary Hodder: updated SG phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-8. THIRD-PARTY LIMITATIONS ==
Wherever [[IDEF Glossary USERS|USERS]] make choices regarding the treatment of their [[IDEF Glossary PERSONAL INFORMATION|personal information]], those choices MUST be communicated effectively by that entity to any [[IDEF Glossary THIRD PARTIES|THIRD-PARTIES]] to which it transmits the personal information.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

One example of a USER's choice that creates a use limitation would be their election to restrict the
use of their personal information to specific purposes only. This Requirement broadly means that
entities convey all such restrictions to the "downstream" recipients of personal information, when they
share that information. However, this Requirement does not dictate what elective choices a USER
should be prompted to make; and it does not require an entity to convey (or enforce) a USER's choices
or instructions if those choices contradict law, regulation or legal process.

Please note, [[Interop Req 6|Requirement INTEROP-6 (THIRD-PARTY COMPLIANCE)]] also includes certain specific
duties in connection with THIRD-PARTIES receiving personal information from an entity.

Responsibilities for liability should be spelled out in agreements between organizations exchanging
personal information in the identity ecosystem, as well as the format and style of the communication of
user-stated privacy preferences and information.

This only applies instances of personal information passed to third parties.

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords NOTICE|NOTICE]], [[IDEF Keywords PORTABILITY|PORTABILITY]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords THIRD PARTIES|THIRD-PARTIES]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 7

2018-06-13T20:42:40Z

Mary Hodder: updated SG for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-7. USER DATA CONTROL ==
Entities MUST provide appropriate mechanisms to enable [[IDEF Glossary USERS|USERS]] to access, correct, and delete [[IDEF Glossary PERSONAL INFORMATION|personal information]].

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and
[[Interop Req 7|INTEROP-7 (USER REDRESS)]].

“Appropriate” broadly means mechanisms for management of personal information should be
effective, easy to use, and accessible. (See [[Usable Req 1|USABLE-1 (USABILITY PRACTICES)]], [[Usable Req 3|USABLE-3 (PLAIN
LANGUAGE)]], and [[Usable Req 5|USABLE-5 (ACCESSIBILITY)]] for guidance on the usability of such mechanisms.)

"Deletion” generally refers to removal of the data from availability. Data disposal, its complete
removal from the complying entity's own systems and control, may depend on the legal and
contractual requirements applicable to the data; see [[Privacy Req 14|PRIVACY-14 (DATA RETENTION AND DISPOSAL)]].

Note: Intermediaries (third parties) may not have direct control over the information that flows through their systems, but should deploy mechanisms that support entity’s ability to conform to this Requirement. See [[Interop Req 6|INTEROP-6 (THIRD-PARTY COMPLIANCE)]].

See the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model] for definition of Transaction Intermediation for the scope of
“intermediaries.” The functional model describes Transaction Intermediation as “Processes and
procedures that limit linkages between transactions and facilitate credential portability." This includes
functions defined as “Blinding,” “Pseudonymization/Anonymization,” and “Exchange.”

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords CHANGES|CHANGES]], [[IDEF Keywords CHOICE|CHOICE]], [[IDEF Keywords CONTROL|CONTROL]], [[IDEF Keywords CORRECTION|CORRECTION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords RETENTION|RETENTION]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 6

2018-06-13T20:41:16Z

Mary Hodder: added roles to updated SG phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-6. USAGE NOTICE ==
Entities MUST provide concise, meaningful, and timely communication to [[IDEF Glossary USERS|USERS]] describing how they collect, generate, use, transmit, and store [[IDEF Glossary PERSONAL INFORMATION|personal information]].

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]].

The goal of notice is to work toward informed consent from USERS: functional requirements should
work toward strategies for improving USERS' understanding of their choices when engaging with
services. Strategies include layered approaches, just-in-time notice, and other examples that can
illustrate effective types of notice mechanism alternatives to privacy policies. In the case of material
changes to the service, entities shall provide clear and conspicuous descriptions of the changes and
their impacts on USERS in advance of the change.

“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 [[Privacy Req 5|PRIVACY-5 (DATA AGGREGATION RISK)]].

See also Requirements [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]] on
the application of limitations to, and scope of, individual transactions and data exchanges.

See also the [[Baseline_Functional_Requirements_v1.0#Usability|IDESG Usability Requirements]] (USABLE-1 through USABLE-7) regarding the clarity of
notices given to USERS and others.

=== 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

The Kantara Consent Receipt is now available (January 2018) in draft form at https://groups.google.com/forum/#!topic/wg-infosharing/553qIdgaq0o

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords NOTICE|NOTICE]], [[IDEF Keywords POLICIES|POLICIES]], [[IDEF Keywords PRIVACY|PRIVACY]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 5

2018-06-13T20:40:09Z

Mary Hodder: added roles for phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-5. DATA AGGREGATION RISK ==
Entities MUST assess the privacy risk of aggregating [[IDEF Glossary PERSONAL INFORMATION|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 [[IDEF Glossary USERS|USER]]'s explicit consent.

=== SUPPLEMENTAL GUIDANCE ===
Regarding "personal information", see [[APPENDIX_A-Defined_Terms|Appendix A]], and [[Privacy Req 1|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 Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]] on
the application of limitations to, and scope of, individual transactions and data exchanges.

See also [[Privacy Req 5 Supplemental Guidance]].

=== 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 ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords AGGREGATION|AGGREGATION]], [[IDEF Keywords CONSENT|CONSENT]], [[IDEF Keywords DESIGN|DESIGN]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords RISK|RISK]]

=== APPLIES TO ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|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]] |

----
----

Privacy Req 4

2018-06-13T20:39:23Z

Mary Hodder: updated SG phase II

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-4. CREDENTIAL LIMITATION ==
Entities MUST NOT request [[IDEF Glossary USERS|USERS]]’ credentials unless necessary for the transaction and then only as appropriate to the risk associated with the transaction or to the risks to the parties associated with the transaction.

=== SUPPLEMENTAL GUIDANCE ===
Intermediaries may not have a direct relationship with individuals whose data moves through their systems,
but should facilitate endpoints' ability to conform to this Requirement.

See the [https://workspace.idesg.org/kws/public/download.php/53/IDEF-Functional-Model-v1.0.pdf IDESG Functional Model] for definition of Transaction Intermediation for the scope of “intermediaries.” The functional model describes Transaction Intermediation as “Processes and
procedures that limit linkages between transactions and facilitate credential portability." This includes
functions defined as “Blinding,” “Psuedonymization/Anonymization,” and “Exchange.”

See Requirements [[Privacy Req 1|PRIVACY-1 (DATA MINIMIZATION)]] and [[Privacy Req 2|PRIVACY-2 (PURPOSE LIMITATION)]] on the application of limitations to, and scope of, individual transactions and data exchanges.

See also [[Privacy Req 4 Supplemental Guidance]].

=== 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 ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords CREDENTIAL|CREDENTIAL]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords LIMITATION|LIMITATION]],
[[IDEF Keywords PRIVACY|PRIVACY]], [[IDEF Keywords PURPOSE|PURPOSE]], [[IDEF Keywords RISK|RISK]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 3

2018-06-13T20:36:37Z

Mary Hodder: /* SUPPLEMENTAL GUIDANCE */

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-3. ATTRIBUTE MINIMIZATION ==
Entities requesting [[IDEF Glossary ATTRIBUTES|attributes]] MUST evaluate the need to collect specific attributes in a transaction, as opposed to claims regarding those attributes. Wherever feasible, entities MUST collect, generate, use, transmit, and store claims about [[IDEF Glossary USERS|USERS]] rather than attributes. Wherever feasible, attributes MUST be transmitted as claims, and transmitted credentials and identities MUST be bound to claims instead of actual attribute values.

=== SUPPLEMENTAL GUIDANCE ===
Where feasible, Identity Providers (and any other entities releasing attributes) should provide the
opportunity for attributes to be released as claims as well as detailed attributes; see also [[Privacy Req 1|PRIVACY-1
(DATA MINIMIZATION)]] on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own legal or business processes to collect and store, although
not necessarily transmit, attributes in their attribute form, in which case significant alteration or
filtering may be required when that data is re-used or transmitted to others.

For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.

See also [[Privacy Req 3 Supplemental Guidance]].

=== 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 ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ATTRIBUTES|ATTRIBUTE]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

Privacy Req 3

2018-06-13T20:35:53Z

Mary Hodder: Added SG and Roles.

''<< Back to [[Baseline_Functional_Requirements_v1.0|Baseline Functional Requirements Index]]''

== PRIVACY-3. ATTRIBUTE MINIMIZATION ==
Entities requesting [[IDEF Glossary ATTRIBUTES|attributes]] MUST evaluate the need to collect specific attributes in a transaction, as opposed to claims regarding those attributes. Wherever feasible, entities MUST collect, generate, use, transmit, and store claims about [[IDEF Glossary USERS|USERS]] rather than attributes. Wherever feasible, attributes MUST be transmitted as claims, and transmitted credentials and identities MUST be bound to claims instead of actual attribute values.

=== SUPPLEMENTAL GUIDANCE ===
Where feasible, Identity Providers (and any other entities releasing attributes) should provide the
opportunity for attributes to be released as claims as well as detailed attributes; see also [[Privacy Req 1|PRIVACY-1
(DATA MINIMIZATION)]] on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own business processes to collect and store, although
not necessarily transmit, attributes in their attribute form, in which case significant alteration or
filtering may be required when that data is re-used or transmitted to others.

For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.

See also [[Privacy Req 3 Supplemental Guidance]].

=== 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 ROLES ===
1 - [[IDEF Glossary RELYING PARTIES|RELYING PARTIES]] 
2 - [[IDEF Glossary IDENTITY PROVIDERS|IDENTITY PROVIDERS]] 
3 - Attribute Providers 
4 – Intermediaries 
5 - Credential Service Providers (where there is user interaction) 

=== APPLIES TO ACTIVITIES ===
[[IDEF Functional Model REGISTRATION|REGISTRATION]], [[IDEF Functional Model CREDENTIALING|CREDENTIALING]], [[IDEF Functional Model AUTHENTICATION|AUTHENTICATION]], [[IDEF Functional Model AUTHORIZATION|AUTHORIZATION]], [[IDEF Functional Model INTERMEDIATION|INTERMEDIATION]]

=== KEYWORDS ===
[[IDEF Keywords ATTRIBUTES|ATTRIBUTE]], [[IDEF Keywords IDENTIFIERS|IDENTIFIER]], [[IDEF Keywords LIMITATION|LIMITATION]], [[IDEF Keywords MINIMIZATION|MINIMIZATION]], [[IDEF Keywords PRIVACY|PRIVACY]]

----
----
Quick Links: [[SALS]] | [[Baseline Functional Requirements v1.0]] | [[Glossary]] |

----
----

2017-08-29T16:32:40Z

Mary Hodder: /* Introduction */

==Introduction==
Any successful [[https://wiki.idesg.org/wiki/index.php?title=Glossary identity]] ecosystem will provide users with an understanding about how they control access to their own [[User Private Information]] which is used by any [[Digital Entity]] on the internet to authorize access to resources that the user wants or needs.

==The Context==
*This modelling exercise is limited to one user using a browser or similar user agent interacting with any one [[Digital Entity]] which contains [[User Private Information]].
*In the IDESG and GDPR, the user has the right to know what data is held about them and to control the use of that data.

==The Problem==
===Problem Summary===
"When a user approaches a GUI, he or she does two things: thinking and doing. For a smooth interaction between man and machine, the computer's "mental" model (also the programmer's mental model) and the end user's mental model must align with each other in kind of mind-meld. In the end, any work that users do on their side of the interface manipulates the objects in the code. If the program provides accurate real-time feedback about how user manipulations affect program state, it reduces user errors and surprises. A good GUI provides this service. Using an interactive program is like being a doctor trying to navigate a probe through a patient's bronchial tubes: just as you can't see the objects in program memory, you can't see the actual probe in the patient's body. You need some external representation of the program structure, or of the bronchial probe, to guide your interaction with a program." This is a direct quote from [http://www.artima.com/articles/dci_vision.html The DCI Architecture: A New Vision of Object-Oriented Programming].

===Historical Solutions===

Ever since SmallTalk at Xerox Parc, the [https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller (MVC)] design pattern has been used by UX designers to give user control of data held on computer systems. The basic assumption is that data held about the user should be modeled in such a way that the user would be able to effectively interact with the data store. On a personal computer this model still works wonderfully. Where it breaks down is data models that must be accessible by many systems on an increasing globalized internetwork of computers. When there is more and one type of system accessing the data, a model is required that handles requests from a wide variety of computer systems with disparate needs. For such a widely accessibly model, some domain of applicability will cover a range of uses, many of which are not attached to any GUI. The domain model is so complex that users cannot be expected to create a mental model of the entire data structure.

More recent identity models have been created around specific data structures held in computer systems with the MVC augmented with separate view-models for each user interaction page. While this allows the design of view models that the user should be able to understand, the separation into distinct view-models for each display does not provide the user with a consistent view of the data that is accessible to them for their information or control. The [https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel Model–view–viewmodel (MVVM)] works well with event driven systems, but a more user-centric identity model is needed to enable users to build a single mental model of their data held in cyberspace.

==A New Model==
The new model proposed for IDESG is one that considers the data held by any [[Digital Entity]] from the user's perspective. In this sense it is like a consistent view-model, except that it is not bound to one data base schema, but to an abstract view that should allow a consistent user experience that will apply to any interaction that the user has with their [[User Private Information]] held by any [[Digital Entity]] on the internet.

This identity model can be considered to be an abstract view-model of [[User Private Information]]. Each designer needs to carefully create a real view-model for their own solution. The objective of this exercise is to provide a the overall framework that will be a paradigm that can be used to create the consistent internal user model of how their data is handled on the internet.

==References and Coordination==
The [[Best Practices and Example for RP System]] provides an example data base schema to show one way that a Relying Party could implement a database schema to achieve the results desired.

The [[Identity Model Overview]] provides a description of the model for business decision makers.

The [[Identity Model]] provides a description of the model for designers and program architects.

Identity Modeling Introduction

2017-08-29T16:32:14Z

Mary Hodder: /* Introduction */

==Introduction==
Any successful [[https://wiki.idesg.org/wiki/index.php?title=Glossary | identity]] ecosystem will provide users with an understanding about how they control access to their own [[User Private Information]] which is used by any [[Digital Entity]] on the internet to authorize access to resources that the user wants or needs.

==The Context==
*This modelling exercise is limited to one user using a browser or similar user agent interacting with any one [[Digital Entity]] which contains [[User Private Information]].
*In the IDESG and GDPR, the user has the right to know what data is held about them and to control the use of that data.

==The Problem==
===Problem Summary===
"When a user approaches a GUI, he or she does two things: thinking and doing. For a smooth interaction between man and machine, the computer's "mental" model (also the programmer's mental model) and the end user's mental model must align with each other in kind of mind-meld. In the end, any work that users do on their side of the interface manipulates the objects in the code. If the program provides accurate real-time feedback about how user manipulations affect program state, it reduces user errors and surprises. A good GUI provides this service. Using an interactive program is like being a doctor trying to navigate a probe through a patient's bronchial tubes: just as you can't see the objects in program memory, you can't see the actual probe in the patient's body. You need some external representation of the program structure, or of the bronchial probe, to guide your interaction with a program." This is a direct quote from [http://www.artima.com/articles/dci_vision.html The DCI Architecture: A New Vision of Object-Oriented Programming].

===Historical Solutions===

Ever since SmallTalk at Xerox Parc, the [https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller (MVC)] design pattern has been used by UX designers to give user control of data held on computer systems. The basic assumption is that data held about the user should be modeled in such a way that the user would be able to effectively interact with the data store. On a personal computer this model still works wonderfully. Where it breaks down is data models that must be accessible by many systems on an increasing globalized internetwork of computers. When there is more and one type of system accessing the data, a model is required that handles requests from a wide variety of computer systems with disparate needs. For such a widely accessibly model, some domain of applicability will cover a range of uses, many of which are not attached to any GUI. The domain model is so complex that users cannot be expected to create a mental model of the entire data structure.

More recent identity models have been created around specific data structures held in computer systems with the MVC augmented with separate view-models for each user interaction page. While this allows the design of view models that the user should be able to understand, the separation into distinct view-models for each display does not provide the user with a consistent view of the data that is accessible to them for their information or control. The [https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel Model–view–viewmodel (MVVM)] works well with event driven systems, but a more user-centric identity model is needed to enable users to build a single mental model of their data held in cyberspace.

==A New Model==
The new model proposed for IDESG is one that considers the data held by any [[Digital Entity]] from the user's perspective. In this sense it is like a consistent view-model, except that it is not bound to one data base schema, but to an abstract view that should allow a consistent user experience that will apply to any interaction that the user has with their [[User Private Information]] held by any [[Digital Entity]] on the internet.

This identity model can be considered to be an abstract view-model of [[User Private Information]]. Each designer needs to carefully create a real view-model for their own solution. The objective of this exercise is to provide a the overall framework that will be a paradigm that can be used to create the consistent internal user model of how their data is handled on the internet.

==References and Coordination==
The [[Best Practices and Example for RP System]] provides an example data base schema to show one way that a Relying Party could implement a database schema to achieve the results desired.

The [[Identity Model Overview]] provides a description of the model for business decision makers.

The [[Identity Model]] provides a description of the model for designers and program architects.