From reading NIST SP 800 63A, I understand that it lists the requirements for parsing, validating, and validating identities and any provided proof of identity. The goal of identity resolution is to uniquely distinguish individuals in a given environment, providing CSPs with an important starting point for the entire authentication process. It includes initial detection of potential fraud, but does not represent a complete and successful authentication transaction. An exact match of the information used in this proofing process may be difficult to achieve. Knowledge-based authentication, on the other hand, is used to verify the claimed identity by testing the applicant’s knowledge against information obtained from public databases.
You make a valid point. An exact match in the proofing process is going to be difficult because you are attempting to prove an individual over an open network as the document states, and so you are leaving a lot of room for impersonation. Knowledge-based as you mentioned seems to be the better alternative.
There are some privacy considerations to make when setting up identity proofing. You should minimize the data your collecting. Especially sensitive data which leaves the individual susceptible to harm through identity theft such as SSNs should only be collected when absolutely necessary. You should also provide explicit notice and gain consent when collecting PII. When an issue comes up in the identity proofing process, they should not inform the user of what the issue is (e.g., wrong SSN) but they should inform the user there was an error.
I had to comment on your post again because your points align perfectly with my ‘in the news’ article regarding the security of PII data. Many Covid apps take in droves of PII data and fail to encrypt the app’s QR codes. The QR codes are responsible for transmitting vaccination information to the requesting party. However, sending this data over HTTP leaves this highly sensitive information vulnerable to man-in-the-middle attacks. It is clear these apps did not adhere to the standards of NIST 800-63.
Per the document: It provides the requirements for enrollment and identity proofing of applications that want to gain access to resources at each identity assurance level. Those levels are:
1. There is no need to link the applicant to a specific real-life identity
2. Evidence supports real-world acceptance of the identity and verifies that the applicant is associated with the identity. This is also where remote or physically present identity proofing is introduced
3. Physical presence is required for identity proofing. Identifying attributes has to be verified by a CSP representative
My main takeaway from this is to help identify the person who is attempting to authenticate
I am interested in the idea that the evidence supports real-world acceptance of identity. I think the introduction of remote or physical proof of identity is with notification and consent, when something goes wrong in the identity proof process, and multi-party authentication is required. Proof of identity for more important proofs requires in-person presence.
There are three IALs defined in NIST SP 800-63A – IAL1, IAL2, and IAL3 – with increasingly stringent requirements.
IAL1: There is no need to map claimed identities to actual people or ensure that users have the asserted identities. IAL1 is the least stringent level and does not require solid proof of identity – digital services do not need to map the person creating the account to a real-life identity. The identity attributes are asserted by the user, not verified, so they do not need to submit evidence.
IAL2: Requires users to submit evidence that they own the identity they claim. IAL2 requires proof of identity and can be done remotely or in person. The person requesting access to the asset must provide evidence that they are the owner of the identity they claim to have. Biometric information, such as facial scans or fingerprints, can be collected.
IAL3: IAL3 is the most stringent level of NIST 800-63-3 identity verification. Requires physical presence, either in person or under remote supervision, and requires a biometric comparison of the applicant to the most substantial identification evidence.
One key takeaway from NIST 800-63A is the drastic difference between IAL1 and IAL2. IAL1 has zero requirements; its sole existence is to create a category in which no identity proofing requirements are needed. There is not a single requirement category in table 4-1 with a specification. IAL2 then jumps to requiring identity evidence, proof of address, optional biometric data collection, and more.
Another thing that jumped out to me from this SP is knowledge-based verification (KBV). I found it fascinating how they use bank account transactions and other types of knowledge that only the recipient should know to verify the recipients identity. In section 5.3.2, it is also stated that “Information accessible freely, for a fee in the public domain, or via the black market SHALL NOT be used.” But, it is also stated that “there are no restrictions to the use of KBV for identity resolution.” I am curious to see how the federal government would perform an in-depth identity resolution in a serious circumstance.
The biggest threat that comes with enrollment and identity proofing is impersonation, namely false identity proofing, fraudulent use of another person’s identity, and enrollment repudiation (a subscriber denying enrollment). False identity proofing can be mitigated by validating the physical security of presented identity evidence and validating personal details with either the issuer or another authoritative source. Fraudulent use of another’s identity can be mitigated by verifying identity evidence and the biometric information of an applicant against a trusted source, and by verifying non-government issued documentation such as utility bills. Enrollment repudiation can be mitigated by saving a subscriber’s biometric for future evidence of enrollment.
As a cyber defense specialist, I am always interested in how adversaries can exploit security measures. Specifically, in section 5.2.8 Replay Resistance, while MFA affords more robust authentication and identity security control than single-factor authentication, we must still be mindful of replay attacks. Replay attacks use cached information (cookies, tokens) to replay an authentication message, allowing an attacker to bypass MFA controls successfully. One-time passcodes (OTP) are an example of replay-resistant authenticators because the attacker would not be able to leverage stored authentication data because a new token is generated each log-on attempt.
NIST 800-63A has included the requirement of the enrollment and identity proofing process prior user getting access to the system. There are three different levels of Identity levels. Identity Assurance Level 1 does not require to link the applicants to a specific real-life identity. Identity Assurance Level 2 requires the user to prove their identity either remotely or in person. Identity Assurance Level 3 takes a step further then level 2 and requires the user to identify using the one of the biometric authentication processes.
I like how you define IAL as being performed before a user gets access to a system. It is critical to prove someones identity before granting them access to a system because repeated authentication of a user who is a fraud or malicious from the start is not digital identity verification at all.
The purpose of the NIST SP-800-63A document is to outline and detail the requirements needed for “enrollment and identity proofing” for applicants at each of the identity assurance levels, or IALs. IAL3 is the most strict, as it specifically requires that physical presence be part of the identity proofing process. Furthermore, the attributes of the identity must also be verified by an authorized CSP representative. An interesting point made regarding IAL2 and IAL3 in the document is that when a birthdate is required, if no other personal details are required, just the birthdate of the subscriber should be in question. If it must be determined that a subscriber is older than 18, just a boolean T/F value should be required, instead of recording the entire birthdate unnecessarily.
Hi Antonio,
Good points were being discussed in your master piece. However, the enrollment and identity proofing process sets the stage for a user’s interactions with a given CSP and the online services that the user will access; as negative first impressions can influence user perception of subsequent interactions, organizations need to promote a positive user experience throughout the process in order to maintain confidentiality, integrity and availability at all times.
Identity resolution is a data management process through which an identity is searched and analyzed between disparate data sets and databases to find a match and/or resolve identities.Identity resolution enables an organization to analyze a particular individual’s or entity’s identity based on its available data records and attributes. The most appropriate identity evidence is a drivers license or a passport. These documents determine its authenticity, validity, and accuracy. Identity validation is made up of three process steps: collecting the appropriate identity evidence, confirming the evidence is genuine and authentic, and confirming the data contained on the identity evidence is valid.
You’ve done an excellent job of explaining how identity resolution works. It helps you understand and analyze unknown website visitors. Anonymous visitors account for around upwards of 98% of all website visitors. Maybe they’re visitors who haven’t converted yet. Or perhaps they have converted but are logged out on arrival. With identity resolution, you can reconcile anonymous visitor data with your known visitor data and get deeper insights into customer behavior than ever before to boost sales and retention.
There are 3 levels to the identity assurance levels. The first level is no requirement regarding the link applicant to specific real life identity. Any attributes should be provided in conjunction with the subject’s activities are self-asserted or should be treated as one.
Level 2- Evidence that supports the real-world existence of the claimed identity and verifies that the applicant is associated with the real-word identity. It introduces the need to either be remote or physically present identity proofing.
At level 3, physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative.
Section 4.1, Process Flow, highlights the basic flow for identifying proofing and enrollment. First, the core attributes and evidence is collected (resolution), then, it is validated, and last, the evidence is verified (CSP asks the applicant for a photo of themselves to match their license and passport).
One important concept from this reading was the basis of identity proofing. Identity proofing ensures that a user is who they claim to be, utilizing presentation of credentials, validation, and verification of minimum attributes necessary to confirm identification. This process authenticates users at each IAL (identity assurance level).
The article talks about the threats and security implications as regards authenticator. An attacker who usually get access to authenticator will pose as the authenticator’s owner. And in that sense, something you know information may be revealed to an attacker and something you have may be stolen, damaged, and lost from the owner, or concealed by an attacker. For instance, the malicious attacker might guess a memorized secret such as a pin or passcode in order to get access to the system.
Finally, another situation is an attacker who gains access to the owner’s computer might copy a software authenticator with the aim of getting access to the system.
NIST SP 800-63-A addresses how applicants can prove their identities within an identity system. It provides requirements by which applicants can both identity and register at one of three risk mitigation levels in both the remote and physically present scenarios. It sets the standard required to achieve an IAL. The three IALs show the alternatives agencies have based on the applicable risk profile and the potential harm from false identity claim Attacks.
The 3 IALs are stated below:
IAL1: There is no requirement to link an applicant to any real-life identity. Any attribute provided in conjunction with the authentication process should be treated as such.
IAL2: In this case, the evidence supports the real-world existence of the claimed identity, and it verifies that the applicant is appropriately associated with this real-world identity. It introduces the need for either remote or physically present identity proofing.
IAL3: In this instance, physical presence is required for proof of identity. Identifying requirements must always be verified by an authorized and trained representative.
From reading NIST SP 800 63A, I understand that it lists the requirements for parsing, validating, and validating identities and any provided proof of identity. The goal of identity resolution is to uniquely distinguish individuals in a given environment, providing CSPs with an important starting point for the entire authentication process. It includes initial detection of potential fraud, but does not represent a complete and successful authentication transaction. An exact match of the information used in this proofing process may be difficult to achieve. Knowledge-based authentication, on the other hand, is used to verify the claimed identity by testing the applicant’s knowledge against information obtained from public databases.
Hi Dan Xu,
You make a valid point. An exact match in the proofing process is going to be difficult because you are attempting to prove an individual over an open network as the document states, and so you are leaving a lot of room for impersonation. Knowledge-based as you mentioned seems to be the better alternative.
There are some privacy considerations to make when setting up identity proofing. You should minimize the data your collecting. Especially sensitive data which leaves the individual susceptible to harm through identity theft such as SSNs should only be collected when absolutely necessary. You should also provide explicit notice and gain consent when collecting PII. When an issue comes up in the identity proofing process, they should not inform the user of what the issue is (e.g., wrong SSN) but they should inform the user there was an error.
Hi Madalyn,
I had to comment on your post again because your points align perfectly with my ‘in the news’ article regarding the security of PII data. Many Covid apps take in droves of PII data and fail to encrypt the app’s QR codes. The QR codes are responsible for transmitting vaccination information to the requesting party. However, sending this data over HTTP leaves this highly sensitive information vulnerable to man-in-the-middle attacks. It is clear these apps did not adhere to the standards of NIST 800-63.
Per the document: It provides the requirements for enrollment and identity proofing of applications that want to gain access to resources at each identity assurance level. Those levels are:
1. There is no need to link the applicant to a specific real-life identity
2. Evidence supports real-world acceptance of the identity and verifies that the applicant is associated with the identity. This is also where remote or physically present identity proofing is introduced
3. Physical presence is required for identity proofing. Identifying attributes has to be verified by a CSP representative
My main takeaway from this is to help identify the person who is attempting to authenticate
Hi Dhaval,
I am interested in the idea that the evidence supports real-world acceptance of identity. I think the introduction of remote or physical proof of identity is with notification and consent, when something goes wrong in the identity proof process, and multi-party authentication is required. Proof of identity for more important proofs requires in-person presence.
There are three IALs defined in NIST SP 800-63A – IAL1, IAL2, and IAL3 – with increasingly stringent requirements.
IAL1: There is no need to map claimed identities to actual people or ensure that users have the asserted identities. IAL1 is the least stringent level and does not require solid proof of identity – digital services do not need to map the person creating the account to a real-life identity. The identity attributes are asserted by the user, not verified, so they do not need to submit evidence.
IAL2: Requires users to submit evidence that they own the identity they claim. IAL2 requires proof of identity and can be done remotely or in person. The person requesting access to the asset must provide evidence that they are the owner of the identity they claim to have. Biometric information, such as facial scans or fingerprints, can be collected.
IAL3: IAL3 is the most stringent level of NIST 800-63-3 identity verification. Requires physical presence, either in person or under remote supervision, and requires a biometric comparison of the applicant to the most substantial identification evidence.
One key takeaway from NIST 800-63A is the drastic difference between IAL1 and IAL2. IAL1 has zero requirements; its sole existence is to create a category in which no identity proofing requirements are needed. There is not a single requirement category in table 4-1 with a specification. IAL2 then jumps to requiring identity evidence, proof of address, optional biometric data collection, and more.
Another thing that jumped out to me from this SP is knowledge-based verification (KBV). I found it fascinating how they use bank account transactions and other types of knowledge that only the recipient should know to verify the recipients identity. In section 5.3.2, it is also stated that “Information accessible freely, for a fee in the public domain, or via the black market SHALL NOT be used.” But, it is also stated that “there are no restrictions to the use of KBV for identity resolution.” I am curious to see how the federal government would perform an in-depth identity resolution in a serious circumstance.
The biggest threat that comes with enrollment and identity proofing is impersonation, namely false identity proofing, fraudulent use of another person’s identity, and enrollment repudiation (a subscriber denying enrollment). False identity proofing can be mitigated by validating the physical security of presented identity evidence and validating personal details with either the issuer or another authoritative source. Fraudulent use of another’s identity can be mitigated by verifying identity evidence and the biometric information of an applicant against a trusted source, and by verifying non-government issued documentation such as utility bills. Enrollment repudiation can be mitigated by saving a subscriber’s biometric for future evidence of enrollment.
As a cyber defense specialist, I am always interested in how adversaries can exploit security measures. Specifically, in section 5.2.8 Replay Resistance, while MFA affords more robust authentication and identity security control than single-factor authentication, we must still be mindful of replay attacks. Replay attacks use cached information (cookies, tokens) to replay an authentication message, allowing an attacker to bypass MFA controls successfully. One-time passcodes (OTP) are an example of replay-resistant authenticators because the attacker would not be able to leverage stored authentication data because a new token is generated each log-on attempt.
NIST 800-63A has included the requirement of the enrollment and identity proofing process prior user getting access to the system. There are three different levels of Identity levels. Identity Assurance Level 1 does not require to link the applicants to a specific real-life identity. Identity Assurance Level 2 requires the user to prove their identity either remotely or in person. Identity Assurance Level 3 takes a step further then level 2 and requires the user to identify using the one of the biometric authentication processes.
Vraj,
I like how you define IAL as being performed before a user gets access to a system. It is critical to prove someones identity before granting them access to a system because repeated authentication of a user who is a fraud or malicious from the start is not digital identity verification at all.
-Mike
The purpose of the NIST SP-800-63A document is to outline and detail the requirements needed for “enrollment and identity proofing” for applicants at each of the identity assurance levels, or IALs. IAL3 is the most strict, as it specifically requires that physical presence be part of the identity proofing process. Furthermore, the attributes of the identity must also be verified by an authorized CSP representative. An interesting point made regarding IAL2 and IAL3 in the document is that when a birthdate is required, if no other personal details are required, just the birthdate of the subscriber should be in question. If it must be determined that a subscriber is older than 18, just a boolean T/F value should be required, instead of recording the entire birthdate unnecessarily.
Hi Antonio,
Good points were being discussed in your master piece. However, the enrollment and identity proofing process sets the stage for a user’s interactions with a given CSP and the online services that the user will access; as negative first impressions can influence user perception of subsequent interactions, organizations need to promote a positive user experience throughout the process in order to maintain confidentiality, integrity and availability at all times.
Identity resolution is a data management process through which an identity is searched and analyzed between disparate data sets and databases to find a match and/or resolve identities.Identity resolution enables an organization to analyze a particular individual’s or entity’s identity based on its available data records and attributes. The most appropriate identity evidence is a drivers license or a passport. These documents determine its authenticity, validity, and accuracy. Identity validation is made up of three process steps: collecting the appropriate identity evidence, confirming the evidence is genuine and authentic, and confirming the data contained on the identity evidence is valid.
Hi Johnson,
You’ve done an excellent job of explaining how identity resolution works. It helps you understand and analyze unknown website visitors. Anonymous visitors account for around upwards of 98% of all website visitors. Maybe they’re visitors who haven’t converted yet. Or perhaps they have converted but are logged out on arrival. With identity resolution, you can reconcile anonymous visitor data with your known visitor data and get deeper insights into customer behavior than ever before to boost sales and retention.
There are 3 levels to the identity assurance levels. The first level is no requirement regarding the link applicant to specific real life identity. Any attributes should be provided in conjunction with the subject’s activities are self-asserted or should be treated as one.
Level 2- Evidence that supports the real-world existence of the claimed identity and verifies that the applicant is associated with the real-word identity. It introduces the need to either be remote or physically present identity proofing.
At level 3, physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative.
Section 4.1, Process Flow, highlights the basic flow for identifying proofing and enrollment. First, the core attributes and evidence is collected (resolution), then, it is validated, and last, the evidence is verified (CSP asks the applicant for a photo of themselves to match their license and passport).
One important concept from this reading was the basis of identity proofing. Identity proofing ensures that a user is who they claim to be, utilizing presentation of credentials, validation, and verification of minimum attributes necessary to confirm identification. This process authenticates users at each IAL (identity assurance level).
The article talks about the threats and security implications as regards authenticator. An attacker who usually get access to authenticator will pose as the authenticator’s owner. And in that sense, something you know information may be revealed to an attacker and something you have may be stolen, damaged, and lost from the owner, or concealed by an attacker. For instance, the malicious attacker might guess a memorized secret such as a pin or passcode in order to get access to the system.
Finally, another situation is an attacker who gains access to the owner’s computer might copy a software authenticator with the aim of getting access to the system.
NIST SP 800-63-A addresses how applicants can prove their identities within an identity system. It provides requirements by which applicants can both identity and register at one of three risk mitigation levels in both the remote and physically present scenarios. It sets the standard required to achieve an IAL. The three IALs show the alternatives agencies have based on the applicable risk profile and the potential harm from false identity claim Attacks.
The 3 IALs are stated below:
IAL1: There is no requirement to link an applicant to any real-life identity. Any attribute provided in conjunction with the authentication process should be treated as such.
IAL2: In this case, the evidence supports the real-world existence of the claimed identity, and it verifies that the applicant is appropriately associated with this real-world identity. It introduces the need for either remote or physically present identity proofing.
IAL3: In this instance, physical presence is required for proof of identity. Identifying requirements must always be verified by an authorized and trained representative.