This section is informative.
These privacy considerations provide additional information for implementing the requirements set forth in Sec. 3.3 and are intended to guide CSPs and RPs in designing identity systems that prioritize protecting their users’ privacy.
These guidelines permit the collection and processing of only the personal information necessary to validate the claimed identity, associate the claimed identity to the applicant, mitigate fraud, and provide RPs with the attributes they may use to make authorization decisions. Processing personal information, including biometric data, that is unnecessary for the identify proofing service can cause individuals to be concerned that their data is being used in ways that exceed their expectations or authorization. This could lead to privacy problems, such as embarrassment, loss of autonomy, or loss of trust. Furthermore, the retention of personal information can become vulnerable to unauthorized access or use. Data minimization reduces the amount of personal information that is vulnerable to unauthorized access or use and encourages trust in the identity proofing process.
These guidelines permit the CSP to collect SSNs as an attribute for use in identity resolution. However, overreliance on the SSN can contribute to misuse and place the applicant at risk of harm, such as through identity theft. Nonetheless, the SSN may facilitate identity resolution for CSPs, particularly federal agencies that use the SSN to correlate an applicant to agency records. This document recognizes the role of the SSN as an attribute and makes appropriate allowances for its use. Knowledge of the SSN is not sufficient to serve as identity evidence.
Where possible, CSPs and agencies should consider mechanisms to limit the proliferation and exposure of SSNs during the identity proofing process. This is particularly pertinent if the SSN is communicated to third-party providers during attribute validation processes. To the extent possible, privacy protection techniques and technologies should be applied to reduce the risk of an individual’s SSN being exposed, stored, or maintained by third-party systems. Examples of this could be the use of attribute claims (e.g., yes/no responses from a validator) to confirm the validity of an SSN without requiring it to be unnecessarily transmitted by the third party. As with all attributes in the identity proofing process, the value and risk of each attribute being processed is subject to a privacy risk assessment, and federal agencies may address it in their associated PIA and SORN documentation. A CSP is permitted to collect an applicant’s SSN if the CSP considers it to be a core attribute or to support identity resolution.
These guidelines require the CSP to provide explicit notice to the applicant at the time of collection regarding the purpose for collecting and maintaining a record of the attributes necessary for identity proofing, including whether such attributes are voluntary or mandatory and the consequences for not providing the attributes. Additionally, Sec. 3.1.11 requires CSPs that collect or process biometric data to provide detailed, publicly available information about this process. An effective notice considers user experience, design standards, research, and an assessment of privacy risks that may arise from the collection. Various factors should be considered, including incorrectly inferring that applicants understand why attributes are collected and that collected information may be combined with other data sources. An effective notice is never only a pointer leading to a complex, legalistic privacy policy or general terms and conditions that applicants are unlikely to read or understand.
Consent allows individuals to participate in making decisions about the processing of their information and transfers some of the risk that arises from the processing of personally identifiable information from the organization to an individual. At a minimum, these guidelines require CSPs to obtain consent from users prior to collecting and using biometric data and prior to recording an identity proofing session, as provided in Sec. 3.1.11. RPs should provide additional guidance to applicants on available choices for the selection of CSPs, identity document requirements, related privacy notices, and alternative means of accessing services.
These guidelines require CSPs to employ measures that maintain predictability (i.e., enabling reliable assumptions by individuals, owners, and operators about the processing of personal information by an information system) and manageability (i.e., providing the capability for the granular administration of personal information, including alteration, deletion, and selective disclosure of personal information) commensurate with the privacy risks that can arise from processing attributes for purposes other than identity proofing, authentication, authorization, attribute assertion, related fraud mitigation, or to comply with laws or legal processes. The NIST Privacy Framework [NIST-Privacy] provides a framework for managing these risks and supporting privacy risk management principles.
CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those disclosed to a subject can create additional privacy risks. CSPs can determine appropriate measures commensurate with the privacy risks that arise from additional processing. For example, absent applicable laws, regulations, or policies, it may not be necessary to obtain consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (i.e., predictability). Other processing of attributes may carry different privacy risks that may call for obtaining consent or giving subscribers more control over the use or disclosure of specific attributes (i.e., manageability). CSPs cannot make the acceptance of these consent measures a condition of using the identity service.
Federal agencies should consult their SAOP if there are questions about whether the proposed processing falls outside of the scope of the permitted processing or the appropriate privacy risk mitigation measures.
These guidelines require the CSP to provide effective and secure mechanisms for redressing applicant complaints or problems that arise from identity proofing and make the mechanisms easy for applicants to find and access.
The Privacy Act requires federal CSPs that maintain a system of records to follow procedures to enable applicants to access and amend their records. Any Privacy Act Statement should include references to applicable SORNs (see Sec. 3.3), which provide the applicant with instructions on how to make a request for access or correction. Non-federal CSPs should have comparable procedures, including contact information for any third parties that are the sources of information.
If an applicant is unable to establish their identity and complete the online enrollment process, CSPs should make the availability of alternative methods for completing the process clear to applicants (e.g., in person at a customer service center).
If the identity proofing process is not successful, CSPs should inform the applicant of the procedures to address the issue but should not inform the applicant of the specifics of why the registration failed (e.g., do not inform the applicant, “Your SSN did not match the one that we have on record for you”), as doing so could allow fraudulent applicants to gain more knowledge about the accuracy of the personal information.
These guidelines require the CSP to conduct a privacy risk assessment. In conducting a privacy risk assessment, CSPs should consider:
These guidelines cover specific compliance obligations for federal CSPs. It is critical to involve an agency’s SAOP in the earliest stages of identity service development to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether the collection of personal information to conduct identity proofing triggers the Privacy Act of 1974 [PrivacyAct] or the E-Government Act of 2002 [E-Gov] requirement to conduct a PIA. For example, with respect to identity proofing, it is likely that Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act SORN due to the collection and maintenance of personal information or other attributes that are necessary to conduct identity proofing.
The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for identity proofing alone. In many cases, it will make the most sense to draft a PIA and SORN that encompass the entire digital identity life cycle or include the identity proofing process as part of a larger, programmatic PIA that discusses the program or benefit to which the agency is establishing online access.
Due to the many components of the digital identity life cycle, it is important for the SAOP to be aware and understand each individual component. For example, other privacy artifacts may be applicable to an agency that offers or uses identity proofing services (e.g., data use agreements, computer matching agreements). The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of identity proofing will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance or other means.