Privacy Risk Assessment Methodology

Privacy Risk Assessment Methodology#

The NIST Privacy Risk Assessment Methodology (PRAM) is a tool that helps organizations analyze, assess, and prioritize privacy risks to determine how to respond and select appropriate solutions. [1] The PRAM can help drive collaboration and communication between various components of an organization, including privacy, cybersecurity, business, and IT personnel.

Taking on the persona of a financial institution, the NCCoE applied the PRAM to assess privacy risk of using an mDL to establish a financial account through online remote identity proofing. The content below is representative of how a financial institution may complete a privacy assessment and is exemplary in nature. It is not intended to be normative in nature, as the responses will vary for each organization. However, completing this process allowed the NCCoE to create a more impactful set of recommendations and improve the build behind our fictitious NCCoE Bank. It is also worth noting that our example PRAM is representative of the mDL request and presentation model only, and does not assess alternative models of identity verification which would likely have different privacy risks. For example, when using document capture of a physical driver’s license there is no selective disclosure of information supported as with mDL. This would introduce different risks and issues with different impacts for the financial institution. A comparable assessment should be conducted of all techniques used by financial institutions for identifying and authenticating its users.

The NIST PRAM is a freely available resource any organization can use. However, financial institutions may extend their existing privacy risk assessment approaches if they have already adopted one. It is recommended that these organization specific approaches consider a detailed evaluation of the data flows and functions of the technology they are evaluating, similar to the method applied in the PRAM.

The sections that follow dive into the completed sample privacy risk assessment, answering five key questions for the (not real) NCCoE Bank (referenced later as “our organization”).

What are the organizational privacy goals?

Frame organizational privacy goals and regulatory context.

What are the organizational privacy goals?#

Mission/business needs the system serves#

The term “digital first” describes the increasing population of customers who prefer to interact on-line rather than through traditional methods, such as making telephone calls or visiting a branch. Pursuing a digital-first strategy prioritizes the customer experience, enables operational scaling, and strengthens security – crucial aspects of our exemplar financial organizational goals. More specifically, using a mobile driver’s license (mDL) for online account establishment and access, serves the following needs of our “digital-first” bank customers:

Customer Convenience: Increased efficacy and accuracy with which customers can present and validate their identity with our online services, reducing the need for customers to make in-person visits to a brick-and-mortar branch and expanding the hours when they can complete identity verification.
Operational Efficiency: Increased automation, reducing manual labor and lowering operational costs.
Customer Empowerment: Self-service options for account opening, enrollment (setting up secure online access), executing transactions and account recovery.
Competitive Advantage: Attracts “digital-first” customers and expands reach to new markets (e.g. customers from various generations, non-local customers [2]^, ^, [3])
Security and Compliance: Advanced security protocols that improve the accuracy of customer information collected for identity verification. Increase ability to report fraud to states whose IDs may be used by bad actors. Improved regulatory compliance for Customer Identification Programs/Customer Due Diligence (CIP/CDD).
Increased Customer Service: Increase the ability of bank tellers to focus more on customer service and less on identifying fraud such as checking counterfeit IDs or explaining to customers that they cannot provide service due to a failed security check.

Privacy-preserving goals of the system#

When customers opt to use an mDL for establishing and accessing an online our exemplar financial institution goals are to ensure the following , they benefit from enhanced privacy protections.

User control and selective data disclosure: Only data required for opening the account is shared, minimizing the data collected and stored—a level of granular data control which is unique to the mobile Driver’s License.
Notice and transparency: Customers are provided with easy-to-understand customer interfaces to enable informed decision-making about sharing their personal information. Additionally, mobile wallets commonly offer customers a record of the organizations with which they have shared their information.
Built-in security: We incorporate strong security into the way we present, store, and transmit customer information. Enabling confidentiality, integrity, and availability of data facilitates controls which double as privacy protections for customer data—such as access control, encryption, and retention/deletion.

Legal environment in which we operate#

Federal Regulations

As a financial institution, our organization is subject to the Financial Modernization Act of 1999, also known as the Gramm-Leach Bliley Act (GLBA), which includes:

The Financial Privacy Rule (governs how financial institutions can collect and disclose customers’ personal financial data),
The Safeguards Rule (requires all financial institutions to maintain safeguards to protect customer information); and
A provision to prevent access to customers’ financial information under false pretenses (“pretexting”).

Source: FTC Financial Privacy

When our customers establish or access an online financial account, we also are subject to Customer Identification Program (CIP) and Customer Due Diligence (CDD) regulations – both falling under the USA PATRIOT Act, aimed at preventing fraud and financial crimes.

Source: FDIC explains the CIP requirements

Cybersecurity and Privacy risk fall under operational risk for our organization. Operational risk is subject to safety and soundness examinations under the FDI act and Federal Reserve Board supervision and regulation letters.

Source: FDI Act Section 39, SR 21-14

State Regulations

In addition, since we operate in California and Oregon, we also must comply with the California Consumer Privacy Act and the Oregon Consumer Privacy Act.

International Regulations

Our mDL efforts will be subject to the regulations in each country where we operate. This PRAM is based upon the requirements of our US operations. Privacy risks should be evaluated for each country where we introduce mDL, either in a separate PRAM or by integrating international considerations into this PRAM.

Contractual Requirements

Certain contracts with key partners include privacy requirements beyond those mandated by law. These may include:

Permissible uses of shared data,
Specific data retention periods and methods of destruction,
Role-based access control for certain data, and
Notification procedures for incidents.

These contractual privacy requirements should also be addressed in the PRAM.

How does the system work?

Identify data and data processing activities.

How does this mDL system work?#

The figure below is an example data flow diagram based on the architecture we have implemented as part of the NCCoE Lab demonstration. This diagram highlights how data flows through our NCCoE Bank and third-party systems to include government and commercial third parties. Each step of the flow elucidates data actions relevant to the PRAM.

Fig. 1. mDL Privacy Assessment Data Flow.

The following table describes the data actions (collection, generation, disclosure, retention, disposal, or transformation) for each of the numbered interaction steps in the

flow in Figure 1.

Data Action	Data
The IDMS collects personal attributes self-asserted by the applicant. Data generation by applicant through a web browser. Data collection by IDMS.	Phone number Email SSN Optionally, preferred names and alternate address
The applicant presents requested attributes from their mDL stored in their digital wallet. The verifier collects the applicant’s attributes from the mDL. Request information passed through the browser. Data collection by verifier.	Driver license number Issuing state Legal name Date of birth Legal address Issue date Expiry date
The verifier confirms that the mDL is valid and discloses the mDL attributes to the IDMS. The verifier disposes of all the mDL attributes in the verifier by deleting them immediately after disclosure. Data transfer from the verifier to IDMS. Data collection by IDMS. Data disposal by the verifier.	Driver license number Issuing state Legal name Date of birth Legal address Issue date Expiry date
The IDMS creates a unique user identifier (UUID) for the applicant and transfers the identifier along with all the attributes (both self-asserted and from the mDL) to the appropriate bank IT back-end applications. Data generation by IDMS. Data transfer from the IDMS to the bank back-end. Data retention by the back end. Data disposal by the IDMS. (Note: FIs retain the attributes of the customer for 7 years from the closure of an account at the bank.)	Phone number Email SSN Preferred name Alternate address Driver license # Issuing state Legal name Date of birth Legal address Issue date Expiry date UUID
The bank validates that the application attributes match the Applicant SSN. SSN verifier responds with “yes” or “no” and disposes of the data sent by the bank back-end. The bank may also validate attributes with third party databases. Data transfer from the bank back-end to the SSN validator. Data disposal by the SSN validator. Self-asserted attributes are validated with a 3^rd party.	SSN Legal name Date of birth Phone number Email
Bank IT back-end processes the information collected and uses its decision logic to determine what financial offering will be made to the customer. Data processed by bank IT back-end Data disposal by the Bank IT back-end. (Note: FIs retain the attributes of the customer for 7 years from the closure of an account at the bank.)	Phone number Email SSN (verified) Preferred name Alternate address Driver license # Issuing state Legal name Date of birth Legal address Issue date Expiry date UUID
Bank creates an account for the applicant and initiates passkey set up via the IDMS. Data transfer from the bank back-end to the IDMS.	UUID
Note: The below items happen outside of the identity verification flow
The third-party trust service distributes the signing public key of mDL issuers. No information about the applicant is disclosed by the trust service in obtaining this public key or distributing these public keys.
The verifier obtains an mDL issuer’s signing public key from the trust service to validate the mDL. No information about the applicant is disclosed to the verifier in obtaining this public key.
A passkey is generated on the client device.

What privacy problems might the system introduce?

Identify privacy problems for individuals arising from data processing.

What potential privacy risks does this mDL system introduce?#

The below table uses the privacy problems for individuals as defined in the NIST PRAM and highlights some of the organization impact that could result if those problems manifested for NCCoE Bank customers.

Data Action	Potential Problems for Individuals
(1) The IDMS collects personal attributes self-asserted by the applicant.	Loss of Trust: Individuals could lose trust in a bank because they’re uncomfortable with how the bank is handling their data. Example: A customer assumes the data they provide is only for account enrollment, then they receive an email marketing mailer that is tailored to their identity. Customers may also lose trust in the bank if they’re asked for sensitive data without knowing why. Example: A customer may not realize SSN is required regardless of mDL, in all financial institution account creation processes.
(2) The applicant presents an mDL from their digital wallet. The verifier collects the applicant’s attributes from the mDL.	Loss of Trust: Customers could lose trust in a bank if the data they collect is beyond what’s predictable or expected. Example: A customer may think only certain attributes from their mDL are transferred, while the bank may actually collect all attributes from the mDL. Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: A customer’s data is sent to a third party without their knowledge or used in a way they were not made explicitly aware of.
(3) The verifier confirms that the mDL is valid and discloses the mDL attributes to the IDMS. The verifier disposes of all the mDL attributes in the verifier by deleting them immediately after disclosure.	Loss of Trust: The customer could lose trust in the bank and its partners because of how they’re handling the customer data. Example: Surveillance (Verifier): If the verifier maintains data about the customer and creates a “shadow profile” for each customer and aggregates their data to craft a narrative about their habits. Surveillance (Issuer): If the verifier directly contacts the issuer to verify each transaction, the issuer could create a pattern of the users’ behaviors and actions online with their mDL. Dignity Loss: An issuer tracking customer activities across transactions could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known.
(4) The IDMS creates a unique user identifier for the applicant and transfers the identifier along with all the attributes (both self-asserted and from the mDL) to the appropriate bank IT back-end applications.	Loss of Trust: If a customer identifier is used to aggregate data about the customer’s transactions beyond the financial institution tenant. Example: Surveillance (IDMS): Customers may be tracked if the IDMS aggregates their transactions across different tenants. IDMS could link transactions across namespaces and domains for well-intended, mission critical reasons (fraud prevention), or other business reasons, some of which may not be compatible with user preferences (marketing) and some that may be nefarious (targeting). Dignity Loss: An IDMS tracking customer activities across tenants could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known. Economic Loss: If customer data is breached at the IDMS, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss.
(5) The bank validates that the application attributes match the Applicant SSN. SSN verifier responds with “yes” or “no” and disposes of the data sent by the bank back-end. The bank may also validate attributes with third party databases.	Loss of Trust: The bank’s business partner may not effectively secure customer data from external actors. Example: Insecurity: The bank’s business partner may suffer a data breach by an external bad actor that results in the leak of the customer’s SSN and other sensitive information, and ultimately in identity theft.
(6) Bank IT back-end processes the information gathered, uses its decision logic to determine what financial offering will be made to the customer.	Discrimination: If assumptions are made about individuals or groups of individuals based on their self-asserted information, this could result in discrimination. Joining this self-asserted data with other datasets could reveal a narrative about an individual. Example: Drawing conclusions about race or financial situation. Economic Loss: Individuals could receive unfair value in a transaction due to discrimination. Example: Assuming credit worthiness based solely on someone’s area code. Additionally, if customer data is breached at the bank back end, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss. Loss of Autonomy: Customers may lose control over how their data is processed, because the bank chooses to process it in a new way internally without proper notice (i.e., secondary use or repurposing). Example: Customers may expect their personal data to be accessed for only certain purposes, such as identity verification when applying for a financial product, but then it is later used for fraud scoring without their consent.
(7) Bank creates an account for the applicant and initiates passkey setup via the IDMS.	Loss of Trust: Customers may lose trust in the bank if they’re unclear on who has access to which data. Example: A customer doesn’t know why they’re interacting with the IDMS instead of the bank. Customers may also lose trust in the bank if they’re asked to present their mDL and attributes each time they authenticate after account creation. Example: If customers are asked to use their mDL for regular authentication, they will need to assert attributes from their mDL each time. Such actions could be perceived as disproportionate to the purpose or outcome of the transaction. Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: Customers may experience stress if they cannot update or delete their information within financial institution systems. Customers may also not be aware of financial institution data retention requirements.

What's the impact of the problems?

Identify the impact to the organization of the problems arising from data processing.

What’s the potential impact to the Financial Institution?#

The below table uses the privacy problems for individuals as defined in the NIST PRAM and highlights some of the organization impact that could result if those problems manifested for NCCoE Bank customers.

Data Action	Potential Problems for Individuals	Impact to the Financial Institution
(1) The IDMS collects personal attributes self-asserted by the applicant.	Loss of Trust: Individuals could lose trust in a bank because they’re uncomfortable with how the bank is handling their data. Example: A customer assumes the data they provide is only for account enrollment, then they receive an email marketing mailer that is tailored to their identity. Customers may also lose trust in the bank if they’re asked for sensitive data without knowing why. Example: A customer may not realize SSN is required regardless of mDL, in all financial institution account creation processes.	The bank may incur direct business costs if customers choose to bank elsewhere because they aren’t comfortable with how banks are using their data.
(2) The applicant presents an mDL from their digital wallet. The verifier collects the applicant’s attributes from the mDL.	Loss of Trust: Customers could lose trust in a bank if the data they collect is beyond what’s predictable or expected. Example: A customer may think only certain attributes from their mDL are transferred, while the bank may actually collect all attributes from the mDL. Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: A customer’s data is sent to a third party without their knowledge or used in a way they were not made explicitly aware of.	If customers are not clear of their choices in how to enroll with or without mDL, if they are not clear on the data collected from the mDL or if their data is used in ways they didn’t predict, they may lose trust in the bank and then choose to do business elsewhere.
(3) The verifier confirms that the mDL is valid and discloses the mDL attributes to the IDMS. The verifier disposes of all the mDL attributes in the verifier by deleting them immediately after disclosure.	Loss of Trust: The customer could lose trust in the bank and its partners because of how they’re handling the customer data. Example: Surveillance (Verifier): If the verifier maintains data about the customer and creates a “shadow profile” for each customer and aggregates their data to craft a narrative about their habits. Surveillance (Issuer): If the verifier directly contacts the issuer to verify each transaction, the issuer could create a pattern of the users’ behaviors and actions online with their mDL. Dignity Loss: An issuer tracking customer activities across transactions could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known.	If third party software that is processing data on the bank’s behalf uses customer data to surveil them, banks may face reputational damage. The bank may incur direct business costs if customers choose to bank elsewhere because they aren’t comfortable with how banks— associated external organizations—are using their data. The bank may incur noncompliance costs if customer data is stored when they’re told it’s deleted, or if it’s used beyond the purposes to which the customers consented. Customers could lose trust in mDLs, driving the financial institution to use less effective and secure means for meeting CIP requirements, opening them up to fraud and customer loss.
(4) The IDMS creates a unique user identifier for the applicant and transfers the identifier along with all the attributes (both self-asserted and from the mDL) to the appropriate bank IT back-end applications.	Loss of Trust: If a customer identifier is used to aggregate data about the customer’s transactions beyond the financial institution tenant. Example: Surveillance (IDMS): Customers may be tracked if the IDMS aggregates their transactions across different tenants. IDMS could link transactions across namespaces and domains for well-intended, mission critical reasons (fraud prevention), or other business reasons, some of which may not be compatible with user preferences (marketing) and some that may be nefarious (targeting). Dignity Loss: An IDMS tracking customer activities across tenants could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known. Economic Loss: If customer data is breached at the IDMS, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss.	If third party software that is processing data on the bank’s behalf uses customer data to surveil them, banks may face reputational damage. The bank may incur direct business costs if customers choose to go elsewhere for banking because they aren’t comfortable with how banks— associated external organizations—are using their data. The bank may incur noncompliance costs if the bank isn’t securely handling sensitive data about the customer.
(5) The bank validates that the application attributes match the Applicant SSN. SSN verifier responds with “yes” or “no” and disposes of the data sent by the bank back-end. The bank may also validate attributes with third party databases.	Loss of Trust: The bank’s business partner may not effectively secure customer data from external actors. Example: Insecurity: The bank’s business partner may suffer a data breach by an external bad actor that results in the leak of the customer’s SSN and other sensitive information, and ultimately in identity theft.	The bank may incur noncompliance costs if the bank isn’t securely handling sensitive data about the customer. Customers may choose to work with other banks if they don’t trust a bank with their data.
(6) Bank IT back-end processes the information gathered, uses its decision logic to determine what financial offering will be made to the customer.	Discrimination: If assumptions are made about individuals or groups of individuals based on their self-asserted information, this could result in discrimination. Joining this self-asserted data with other datasets could reveal a narrative about an individual. Example: Drawing conclusions about race or financial situation. Economic Loss: Individuals could receive unfair value in a transaction due to discrimination. Example: Assuming credit worthiness based solely on someone’s area code. Additionally, if customer data is breached at the bank back end, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss. Loss of Autonomy: Customers may lose control over how their data is processed, because the bank chooses to process it in a new way internally without proper notice (i.e., secondary use or repurposing). Example: Customers may expect their personal data to be accessed for only certain purposes, such as identity verification when applying for a financial product, but then it is later used for fraud scoring without their consent.	The bank may face noncompliance costs if data is not used for the purposes approved/expected. The bank may incur direct business costs if they are making inaccurate assumptions about customers and maintain poor-quality data. The bank may incur noncompliance costs if the bank isn’t securely handling sensitive data about the customer.
(7) Bank creates an account for the applicant and initiates passkey setup via the IDMS.	Loss of Trust: Customers may lose trust in the bank if they’re unclear on who has access to which data. Example: A customer doesn’t know why they’re interacting with the IDMS instead of the bank. Customers may also lose trust in the bank if they’re asked to present their mDL and attributes each time they authenticate after account creation. Example: If customers are asked to use their mDL for regular authentication, they will need to assert attributes from their mDL each time. Such actions could be perceived as disproportionate to the purpose or outcome of the transaction. Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: Customers may experience stress if they cannot update or delete their information within financial institution systems. Customers may also not be aware of financial institution data retention requirements.	The bank may face reputational damage if customers’ data is accessible by organizations they didn’t expect, or if there are security issues. The bank may incur direct business costs if customers choose to go bank elsewhere because they don’t have control over their data.

How do we address the problems?

Select controls to address system requirements and mitigate prioritized privacy risks.

How do we mitigate these risks?#

The below table highlights controls that can help mitigate problems to individuals and impact to banks. For a complete rationale for why these controls were chosen, please refer to our excel mapping here.

Note: The Privacy Framework subcategories below align with the Initial Public Draft of the Privacy Framework version 1.1.

Problems

Controls

(1) The IDMS collects personal attributes self-asserted by the applicant.

Loss of Trust: Individuals could lose trust in a bank because they’re uncomfortable with how the bank is handling their data. Example: A customer assumes the data they provide is only for account enrollment, then they receive an email marketing mailer that is tailored to their identity.

Customers may also lose trust in the bank if they’re asked for sensitive data without knowing why. Example: A customer may not realize SSN is required regardless of mDL, in all financial institution account creation processes.

NIST SP 800-53r5 Controls

PT-02: Data tagging enables more effective data management.
AC-03: Access enforcement is important for compliance obligations and to protect data from malicious actors, or unauthorized uses.
PT-05: Just-in-time notice helps bring transparency to customers about how their data is processed.
PT-04: Consent is important for enabling customer’s decision making in how their data is processed.
PM-22: Quality management ensures there are avenues for customers to seek correction or deletion of their information.
SC-12: Cryptographic protection can be used for data at rest or in transit.
SA-08: Data Minimization helps the bank to only collect what’s needed and reduce the data the bank needs to store. mDL enables selective disclosure of only the necessary attributes.

Privacy Framework 1.1 Subcategories

ID.IM-P5: The purposes for the data actions are inventoried.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
CM.PO-P1: Transparency policies, processes, and procedures for communicating data processing purposes, practices, and associated privacy risks are established and in place.
CT.PO-P3: Policies, processes, and procedures for enabling individuals’ data processing preferences and requests are established and in place.
CT.PO-P4: A data life cycle to manage data is aligned and implemented with the system development life cycle to manage systems.
CM.AW-P8: Individuals are provided with mitigation mechanisms (e.g., credit monitoring, consent withdrawal, data alteration or deletion) to address impacts of problematic data actions.
GV.MT-P7: Policies, processes, and procedures for receiving, tracking, and responding to complaints, concerns, and questions from individuals about organizational privacy practices are established and in place.
ID.RA-P6: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are assessed using a privacy risk assessment process.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
PR.DS-P1: The confidentiality, integrity, and availability of data-at-rest are protected.
PR.DS-P2: The confidentiality, integrity, and availability of data-in-transit are protected.
PR.DS-P9: The confidentiality, integrity, and availability of data-in-use are protected.

(2) The applicant presents requested attributes from their mDL stored in their digital wallet. The verifier collects the applicant’s attributes from the mDL.

Loss of Trust: Customers could lose trust in a bank if the data they collect is beyond what’s predictable or expected. Example: A customer may think only certain attributes from their mDL are transferred, while the bank may actually collect all attributes from the mDL.

See loss of trust controls for data action 1. These controls apply to both the IDSM in data action 1 as well as the verifier in data action 2. In some architectures the verifier may be an element of the IDMS.

Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: A customer’s data is sent to a third party without their knowledge or used in a way they were not made explicitly aware of.

NIST SP 800-53r5 Controls

SR-06: Supplier assessments and reviews are important for securing the broader supply chain when vendors are involved in data processing.

Privacy Framework 1.1 Subcategories

CM.AW-P8: Individuals are provided with mitigation mechanisms (e.g., credit monitoring, consent withdrawal, data alteration or deletion) to address impacts of problematic data actions.
ID.BE-P4: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are identified and prioritized.
ID.RA-P6: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are assessed using a privacy risk assessment process.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
PR.DS-P1: The confidentiality, integrity, and availability of data-at-rest are protected.
PR.DS-P2: The confidentiality, integrity, and availability of data-in-transit are protected.
PR.DS-P9: The confidentiality, integrity, and availability of data-in-use are protected.

(3) The verifier confirms that the mDL is valid and discloses the mDL attributes to the IDMS. The verifier disposes of all the mDL attributes in the verifier by deleting them immediately after disclosure.

Loss of Trust: The customer could lose trust in the bank and its partners because of how they’re handling the customer data. Example:

Surveillance (Verifier): If the verifier maintains data about the customer and creates a “shadow profile” for each customer and aggregates their data to craft a narrative about their habits.
Surveillance (Issuer): If the verifier directly contacts the issuer to verify each transaction, the issuer could create a pattern of the users’ behaviors and actions online with their mDL.

Dignity Loss: An issuer tracking customer activities across transactions could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known.

NIST SP 800-53r5 Controls

CA-07: Continuous Monitoring is important to ensure privacy controls are implemented as expected.
SC-12: Cryptographic protection can be used for data at rest or in transit.
SI-12: Information management and retention – including data disposal - helps the bank meet compliance obligations and reduces the data they need to store and protect.
IA-02: Identification and Authentication is important for ensuring only those who are authorized to access personal data can do so.
SR-06: Supplier assessments and reviews are important for securing the broader supply chain when vendors are involved in data processing.

Device retrieval – a verification model that allows the verifier to independently verify the integrity and accuracy of the user’s attributes without contacting the issuer at transaction time. Server retrieval is not supported.

Privacy Framework 1.1 Subcategories

GV.DE-P4: Data processing ecosystem parties are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual, interoperability framework, or other obligations.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
PR.AA-P1: Identities and credentials for authorized individuals, services, and hardware are managed by the organization.
PR.AA-P2: Identities are proofed and bound to credentials based on the context of interactions.
ID.BE-P4: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are identified and prioritized.
ID.RA-P6: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are assessed using a privacy risk assessment process.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
PR.DS-P1: The confidentiality, integrity, and availability of data-at-rest are protected.
PR.DS-P2: The confidentiality, integrity, and availability of data-in-transit are protected.
PR.DS-P9: The confidentiality, integrity, and availability of data-in-use are protected.

(4) The IDMS creates a unique user identifier (UUID) for the applicant and transfers the identifier along with all the attributes (both self-asserted and from the mDL) to the appropriate bank IT back-end applications.

Loss of Trust: If a customer identifier is used to aggregate data about the customer’s transactions beyond the financial institution tenant. Example:

Surveillance (IDMS): Customers may be tracked if the IDMS aggregates their transactions across different tenants. IDMS could link transactions across namespaces and domains for well-intended, mission critical reasons (fraud prevention), or other business reasons, some of which may not be compatible with user preferences (marketing) and some that may be nefarious (targeting).

Dignity Loss: An IDMS tracking customer activities across tenants could lead to stress or embarrassment. Example: Issuer uses a series of transactions to piece together habits of the customer, or aspects of the customer’s identity, which they do not expect or want to be known.

NIST SP 800-53r5 Controls

IA-02: Identification and Authentication is important for ensuring only those who are authorized to access personal data, can do so.
SC-12: Cryptographic protection can be used for data at rest or in transit.
SI-12: Information management and retention – including data disposal - helps the bank meet compliance obligations and reduces the data they need to store and protect.
PT-03: Personally identifiable information processing purposes limits the use of data to only that which is approved.
SR-06: Supplier assessments and reviews are important for securing the broader supply chain when vendors are involved in data processing.

Unique identifiers are randomly generated so they aren’t inherently revealing about an individual.

Privacy Framework 1.1 Subcategories

GV.DE-P4: Data processing ecosystem parties are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual, interoperability framework, or other obligations.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
ID.IM-P5: The purposes for the data actions are inventoried.
ID.BE-P4: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are identified and prioritized.
ID.RA-P6: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are assessed using a privacy risk assessment process.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
PR.DS-P1: The confidentiality, integrity, and availability of data-at-rest are protected.
PR.DS-P2: The confidentiality, integrity, and availability of data-in-transit are protected.
PR.DS-P9: The confidentiality, integrity, and availability of data-in-use are protected.

Economic Loss: If customer data is breached at the IDMS, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss.

NIST SP 800-53r5 Controls

AC-06: Least privilege is valuable for ensuring data is not comingled and broadly accessible beyond what’s required.
SC-07: Boundary Protection is helpful for limiting data comingling across distinct datasets and preventing unapproved processing.

Privacy Framework 1.1 Subcategories

CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
PR.DS-P1: The confidentiality, integrity, and availability of data-at-rest are protected.
PR.DS-P2: The confidentiality, integrity, and availability of data-in-transit are protected.
PR.DS-P9: The confidentiality, integrity, and availability of data-in-use are protected.
PR.IR-P1: Networks and environments are protected from unauthorized logical access and usage.

(5) The bank validates that the applicant attributes match a valid SSN record. SSN verifier responds with “yes” or “no” and disposes of the data sent by the bank back-end. The bank may also validate attributes with third party databases.

Loss of Trust: The bank’s business partner may not effectively secure customer data from external actors. Example:

Insecurity: The bank’s business partner may suffer a data breach by an external bad actor that results in the leak of the customer’s SSN and other sensitive information, and ultimately in identity theft.

NIST SP 800-53r5 Controls

IA-02: Identification and Authentication is important for ensuring only those who are authorized to access personal data, can do so.
SI-12: Information management and retention – including data disposal - helps the bank meet compliance obligations and reduces the data they need to store and protect.
SC-12: Cryptographic protection can be used for data at rest or in transit.
SR-06: Supplier assessments and reviews are important for securing the broader supply chain when vendors are involved in data processing.

Use of Social Security Administration’s SSN Verifier incorporates a secure approach to verification.

Privacy Framework 1.1 Subcategories

PR.AA-P1: Identities and credentials for authorized individuals, services, and hardware are managed by the organization.
PR.AA-P2: Identities are proofed and bound to credentials based on the context of interactions.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
CT.DP-P2: Data are processed to limit the identification of individuals (e.g., de-identification privacy techniques, tokenization).
CT.DP-P3: Data are processed to limit the formulation of inferences about individuals’ behavior or activities (e.g., data processing is decentralized, distributed architectures).
ID.BE-P4: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are identified and prioritized.
ID.RA-P6: Data processing ecosystem parties (e.g., service providers, customers, partners, product manufacturers, application developers) are assessed using a privacy risk assessment process.

(6) Bank IT back-end processes the information collected and uses its decision logic to determine what financial offering will be made to the applicant.

Discrimination: If assumptions are made about individuals or groups of individuals based on their self-asserted information, this could result in discrimination. Joining this self-asserted data with other datasets could reveal a narrative about an individual. Example: Drawing conclusions about race or financial situation.

NIST SP 800-53r5 Controls

SA-08: Data Minimization is important for limiting the data processed to only that which is needed for the decision logic.

Privacy Framework 1.1 Subcategories

CT.PO-P4: A data life cycle to manage data is aligned and implemented with the system development life cycle to manage systems.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
CT.DP-P2: Data are processed to limit the identification of individuals (e.g., de-identification privacy techniques, tokenization).
CT.DP-P3: Data are processed to limit the formulation of inferences about individuals’ behavior or activities (e.g., data processing is decentralized, distributed architectures).
CT.DP-P4: System or device configurations permit selective collection or disclosure of data elements.
CT.DP-P5: Attribute values are substituted with derived attribute values (e.g., providing an “age older than” statement rather than the actual age).

Economic Loss: Individuals could receive unfair value in a transaction due to discrimination. Example: Assuming credit worthiness based solely on someone’s area code.

Additionally, if customer data is breached at the bank back end, this leak may be used to defraud the individual. Example: A nefarious actor could use leaked data to phish a customer and steal their identity, which could result in significant economic loss.

NIST SP 800-53r5 Controls

AC-03: Access Enforcement - Individual Access enables individuals to review what information about them the bank holds - which gives individuals more predictability and manageability of their own data.

Privacy Framework 1.1 Subcategories

PR.PS-P1: Configuration management practices are established and applied.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
CT.PO-P3: Policies, processes, and procedures for enabling individuals’ data processing preferences and requests are established and in place.
CT.DM-P1: Data Elements can be accessed for review.
CT.DM-P2: Data elements can be accessed for transmission or disclosure.
CT.DM-P3: Data elements can be accessed for alteration.
CT.DM-P4: Data elements can be accessed for deletion.

Loss of Autonomy: Customers may lose control over how their data is processed, because the bank chooses to process it in a new way internally without proper notice (i.e., secondary use or repurposing). Example: Customers may expect their personal data to be accessed for only certain purposes, such as identity verification when applying for a financial product, but then it is later used for fraud scoring without their consent.

NIST SP 800-53r5 Controls

PT-02: Data tagging enables more effective data management.
PT-03: Personally identifiable information processing purposes limits the use of data to only that which is approved.

Privacy Framework 1.1 Subcategories

ID.IM-P5: The purposes for the data actions are inventoried.

(7) Bank creates an account for the approved applicant and initiates passkey set up via the IDMS.

Loss of Trust: Customers may lose trust in the bank if they’re unclear on who has access to which data. Example: A customer doesn’t know why they’re interacting with the IDMS instead of the bank.

Customers may also lose trust in the bank if they’re asked to present their mDL and attributes each time they authenticate after account creation. Example: If customers are asked to use their mDL for regular authentication, they will need to assert attributes from their mDL each time. Such actions could be perceived as disproportionate to the purpose or outcome of the transaction.

NIST SP 800-53r5 Controls

IA-02: Identification and Authentication is important for ensuring only those who are authorized to access personal data, can do so.
AC-03: Access Enforcement - Individual Access enables individuals to review what information about them the bank holds - which gives individuals more predictability and manageability of their own data.
PM-26: Complaint Management offers a mechanism for individuals to raise concerns about privacy practices - crucial for individuals’ ongoing participation in their personal data processing.

Pseudonymous Authentication - Using authentication methods (e.g., passkeys) that does not require the assertion of user attributes as part of the authentication protocol.

Privacy Framework 1.1 Subcategories

PR.AA-P1: Identities and credentials for authorized individuals, services, and hardware are managed by the organization.
PR.AA-P2: Identities are proofed and bound to credentials based on the context of interactions.
PR.PS-P1: Configuration management practices are established and applied.
CT.PO-P2: Policies, processes, and procedures for enabling data review, transfer, sharing or disclosure, alteration, and deletion are established and in place (e.g., to maintain data quality, manage data retention).
CT.PO-P3: Policies, processes, and procedures for enabling individuals’ data processing preferences and requests are established and in place.
CT.DM-P1: Data Elements can be accessed for review.
CT.DM-P2: Data elements can be accessed for transmission or disclosure.
CT.DM-P3: Data elements can be accessed for alteration.
CT.DM-P4: Data elements can be accessed for deletion.
PR.PS-P1: Configuration management practices are established and applied.
CT.DP-P1: Data are processed to limit observability, linkability, and singling out (e.g., data actions take place on local devices, privacy-preserving cryptography).
CT.DP-P2: Data are processed to limit the identification of individuals (e.g., de-identification privacy techniques, tokenization).

Loss of Autonomy: A perceived loss of customer control over how their data is used. Example: Customers may experience stress if they cannot update or delete their information within financial institution systems. Customers may also not be aware of financial institution data retention requirements.

NIST SP 800-53r5 Controls

PM-26: Complaint Management offers a mechanism for individuals to raise concerns about privacy practices - crucial for individuals’ ongoing participation in their personal data processing.

Privacy Framework 1.1 Subcategories

CM.AW-P2: Mechanisms for obtaining feedback from individuals (e.g., surveys or focus groups) about data processing and associated privacy risks are established and in place.
GV.MT-P7: Policies, processes, and procedures for receiving, tracking, and responding to complaints, concerns, and questions from individuals about organizational privacy practices are established and in place.