The following list of FAQs for Special Publication (SP) 800-63, Digital Identity Guidelines addresses recurring inquiries to provide additional clarification to stakeholders. As new questions arise, we will update these FAQs.
Questions and comments can be submitted via GitHub or email.
General
Q-1: Why were identity proofing, authentication, and federation separated into distinct categories?
Q-2: Each xAL has only three levels. Why change from four levels to three?
Q-3: When does SP 800-63 apply to federal agencies?
Q-4: Should I always use the highest xAL? How do I know which xAL to choose?
Q-5: Are usernames considered personal information?
Q-6: Is there a template you can share that reflects the new assurance levels, impact levels, etc. per 800-63-3?
Q-7: Are CSPs (or operators of CSPs) required to be United States citizens?
Q-8: What is considered to be “comparable” when discussing “compensating controls?” If agencies wish to use a compensating control, does it need to be “equivalent” to the original normative control?
Identity Proofing
Q-A1: What is the difference between the conventional proofing process and using a trusted referee at IAL2?
Q-A2: What is the difference between supervised remote identity proofing and unsupervised remote identity proofing?
Q-A3: If employees’ fingerprints are collected for a background investigation, is it necessary for a CSP to do an additional fingerprint check?
Q-A4: How can knowledge-based verification (KBV) be used in identity proofing at IAL2 or IAL3?
Authentication
Q-B01: What is a RESTRICTED authenticator and what do providers have to do differently if they use one?
Q-B02: Can you provide a more detailed description of “risk-based or adaptive authentication techniques” as mentioned in NIST SP 800-63B?
Q-B03: What is authentication intent?
Q-B04: What is verifier impersonation resistance?
Q-B05: Is password expiration no longer recommended?
Q-B06: Are password composition rules no longer recommended?
Q-B07: Is use of knowledge-based authentication permitted?
Q-B08: What should be in the list of common memorized secrets that is described in SP 800-63B section 5.1.1.2?
Q-B09: Why are the timeout requirements so short for AAL2 and AAL3?
Q-B10: Does SP 800-63B require that we remove our password composition (complexity) rules?
Q-B11: Is the use of email acceptable in two-factor authentication?
Q-B12: What is NIST’s position on the use of password managers?
Q-B13: Is the use of biometrics acceptable in multifactor authentication?
Q-B14: Does the guidance on memorized secrets (passwords) apply to system accounts (functional IDs) as well as human users?
Q-B15: Is it permissible to use sets of questions and answers stored by the subscriber for password reset?
Q-B16: Are cloud-based verifiers used by government agencies at AAL2 required to meet FIPS 140 requirements?
Q-B17: SP 800-63B Section 5.1.1.2, Memorized Secret Verifiers, says that a memory-hard password derivation SHOULD be used. PBKDF2, which is extensively used, is not memory-hard. What are examples of memory-hard functions that meet this requirement?
Q-B18: When do FIPS 140 requirements apply to authenticators used at AAL2?
Q-B19: Should substrings of memorized secrets be checked against the blocklist of common passwords?
Federation and Assertions
Q-C01: What is an attribute reference and an attribute value, and why are these terms used?
Q-C02: What is disclosure of information for security purposes?
Q-C03: How do I reach FAL3?
Q-C04: What’s an “authorization component”, how do I get one, and how do I use it?
Q-C05: Is an assertion a kind of authenticator or credential?
Q-C06: Does the use of TLS satisfy the requirement for assertion encryption at FAL2?
Q-C07: If I accept a PIV certificate issued by another organization, is that federation?
Q-C08: Are APIs and access tokens covered by FAL?
Q-C09: Can a digital identity wallet be an IdP?
Q-C10: Do I need to use FAL2 for backchannel assertions?
As the market has matured, so has our guidance. Based on feedback from industry, and in consultation and collaboration with the White House Office of Management and Budget (OMB), we concluded that separating these three items is much more in line with how digital identity gets done in the marketplace. Individual assurance levels that can be mixed and matched provide agencies with opportunities for greater flexibility, more user convenience, enhanced privacy, and reduced risk. No brainer, right?
Instead of a single assurance level for identity proofing, authenticators, and federations, agencies can combine each element based on their risk tolerance, user populations, and the desired outcomes of the digital services they are offering. SP 800-63-3 includes a set of “choose your own adventure” flowcharts to facilitate the process of selecting the appropriate identity proofing, authenticator, or federation assurance levels – also known as “xALs.” With these flowcharts, organizations perform a risk assessment, answer a set of functional questions, and, based on their responses, identify the most appropriate xAL for their system and users.
This flexibility also asks agencies to think innovatively about their system’s privacy requirements. This includes pseudonymous interactions even when strong, multi-factor authenticators are used. In a nutshell, the new version gives agencies the flexibility to deploy strong authentication while avoiding unnecessary proofing of users’ identities that would require collecting (and then protecting) sensitive information. This was not possible in previous versions of the document, where proofing and authentication requirements were bound together in a single assurance level. The new guidelines also require federated identity providers (IdPs) to support a range of options for querying data, like using attribute references (e.g., asserting whether an individual is older than a certain age as opposed to sharing the entire date of birth).
A few reasons:
We did not take this decision lightly, as many federal systems are operating at LOA2. Yet after the analysis, and obtaining buy-in from OMB, we made the update to enable federal systems to effectively respond to modern vulnerabilities. Switching to three levels within each assurance component provides greater security and privacy benefits and gives agencies flexibility to better meet their mission and constituent needs. Federation Assurance Levels (FALs) represent a complete revamp from prior versions, giving greater attention to federated architectures that are becoming – and we expect will continue to become – more prominent over time.
Agencies make the risk determinations for their systems so we don’t set those rules. That said, OMB offers some good information in OMB Circular A-130, stating that legacy systems, specifically those in production on or before June 22, 2017, have 12 months to comply with a new publication, while systems currently in development or undergoing a major transformation need to use the current revision when deployed. For completeness, the language from OMB Circular A-130 states (emphasis ours):
“For legacy information systems, agencies are expected to meet the requirements of, and be in compliance with, NIST standards and guidelines within one year of their respective publication dates unless otherwise directed by OMB. The one-year compliance date for revisions to NIST publications applies only to new or updated material in the publications. For information systems under development or for legacy systems undergoing significant changes, agencies are expected to meet the requirements of, and be in compliance with, NIST standards and guidelines immediately upon deployment of the systems.”
Importantly, we’re not just finalizing SP 800-63 and throwing it over the wall. We’re here to help agencies get it right all the way into production. As needs are identified, we will consider additional resources to support agency implementations. These resources will not contain additional normative requirements, but will instead provide further discussion, technology-specific examples, and details to support implementation of the guidelines. As agencies implement SP 800-63 for their specific use cases, we plan to be available to answer questions, provide clarifications regarding the guidelines, and apply any implementation-specific lessons learned to future revisions.
There is always a trade-off in choosing the appropriate level across all categories. Higher levels do come with greater security and assurance, but at the cost of greater complexity, overhead, and potential for failure. Therefore, it is not always a matter of choosing the highest possible level and then conforming to that. Instead, the risks and potential attacks against a given application need to be considered alongside the costs of implementing a given level. It is always possible for an implementation of an identity system to exceed the requirements of its levels in practice, and the assurance levels themselves have been designed to be subsumptive, such that fulfilling requirements for level 3 automatically fulfills (and in fact exceeds) the requirements for level 2 and level 1 of that category as well. The core document of 800-63-3 section 6 provides detailed discussion on choosing an appropriate combination of xALs.
An identifier (username) is considered to be personally identifiable information (PII) if it contains identifying information that links back to a specific person, and is not if it is chosen arbitrarily by the user or is an opaque value that cannot be linked to a specific person. To illustrate, Facebook identifiers are PII because their Terms of Use require the use of your real name. Unverified Twitter handles (without the blue verified badge) may not be considered PII if they cannot be linked to the specific person, although the user profile for the Twitter account usually does contain PII.
Additional guidance can be found in NIST Special Publication 800-122: Guide to Protecting the Confidentiality of Personally Identifiable Information (PII).
The previous e-authentication risk assessment methodology was replaced by new guidelines. The new guidelines consist of 4 volumes:
– SP 800-63-3 - Digital Identity Guidelines
Please refer to Section 5 Digital Identity Risk Management and Section 6 Selecting Assurance Levels of SP 800-63-3. Section 5.2 Assurance Levels defines the assurance levels for Identity Assurance (IAL), Authentication Assurance (AAL), and Federation Assurance (FAL); these assurance levels replace the previous 4 levels of assurance in SP 800-63-2. Section 5.3 Risk and Impacts presents methodology for performing risk assessments and impact analyses to determine appropriate assurance levels.
Section 6 Selecting Assurance Levels presents direction for selecting appropriate assurance levels based on risk assessments and impact analyses; specifically, Table 6.1 presents potential impacts by impact category for each assurance level. The three following sections — 6.1, 6.2, and 6.3 — present decision trees for the selection of appropriate assurance for each type: IAL, AAL and FAL. Sections 5 and 6 in SP 800-63-3 are intended to be used together as guidance to agencies performing risk assessments, impact analyses, and selection of appropriate assurance levels.
SP 800-63-3 and SP 800-63A do not require CSPs, or the operators of CSPs, to be U.S. citizens.
The Digital Identity Guidelines are intended to provide a baseline of controls that can be consistently applied at different agencies to support interoperability and consistent risk mitigation across agencies. However, we also seek to provide agencies with the flexibility they need to address their specific user populations and threat environments. As such, under section 5.4 of NIST SP 800-63-3 it is stated that:
Agencies MAY determine alternatives to the NIST-recommended guidance, for the assessed xALs, based on their mission, risk tolerance, existing business processes, special considerations for certain populations, availability of data that provides similar mitigations to those described in this suite, or due to other capabilities that are unique to the agency.
Agencies SHALL demonstrate comparability of any chosen alternative, to include any compensating controls, when the complete set of applicable SP 800-63 requirements is not implemented.
As used in the guidance the concept of “comparability” refers to the capacity of different controls to mitigate the same risks – to the greatest degree possible - when a normative control may not be technically viable or implementable for an organization’s user population. This concept exists in NIST guidance to allow agencies a degree of flexibility in implementation. Controls designed to address risks in one step in the identity lifecycle do not by default address risks in another step, however, and agencies should be careful to avoid conflating different controls’ purpose and value. For example, agencies should not seek to replace a verification method – such as a physical comparison of the facial portrait on a piece of identity evidence to the face of the individual – with additional validation methods, such as collecting more data to validate against an authoritative source. These controls do not address the same risks (theft or misuse of valid evidence) and are therefore not comparable in nature.
All alternatives need to be documented and justified in the Agency’s Digital Identity Risk Acceptance statement. It is also recommended that any potential residual risks related to the use of compensating controls are included in any documentation – though this is not explicitly required by current guidance.
We recognize that the language in the document is somewhat confusing. In our attempt to use standards-based terms like SHALL and SHOULD, avoiding terms like “unless” and “if,” this section got a little bloated. The requirement, in layman’s terms, is that agencies should make every effort to proof individuals according to the conventional proofing process laid out in Section 4.4.1 of SP 800-63A. However, we know there are scenarios where the conventional proofing process, either remote or in person, is not going to work for all constituents. In other words, some individuals will just not be able to pass the conventional process or even have the identity evidence required by the conventional process. Nonetheless, we don’t want this to be a barrier for, say, a homeless veteran with no, or a lack of, documentation. This is why we added the ability to use “trusted referees,” such as notaries, that can assist agencies in establishing a digital identity for the applicant. This gives agencies greater flexibility to determine what works best for their stakeholders and their risk tolerance. Ultimately the agency needs to define a process, but there is a catch or two. First, trusted referees can be used to achieve IAL2, but not IAL3. Second, as an individual builds, or rebuilds, evidence of their identity, we want agencies to regularly attempt to re-proof any individual who has completed the trusted referee process via the conventional process.
Supervised remote identity proofing is an equivalent approach to in-person proofing and requires a robust set of features. This includes high-resolution video monitoring through an agency-controlled device (e.g., not an applicant’s personal phone), a trained operator on the other end of the video, and a number of other security controls. If those controls are all met, supervised remote identity proofing can achieve IAL3. Supervised remote identity proofing is also perfectly fine for IAL2. Unsupervised remote proofing can be used for IAL2 but not IAL3. It does not require that a remote operator participate in the session with the applicant, and typically involves commodity hardware and services that users and agencies can easily access.
SP 800-63A Section 4.5.7 requires a biometric to be captured at the time of identity proofing at IAL3. The fingerprint collected for a background investigation is a discrete event for a different purpose; the intention of section 4.5.7 is for the CSP to bind a biometric captured during the identity proofing event to the subject’s identity account and associated authenticator(s) for purposes of identity account management (e.g., non-repudiation, re-proofing, or authenticator replacement). Conformance to SP 800-63A IAL3 requires the CSP to collect this biometric sample during the identity proofing event and maintain a record of that biometric in the subject’s identity account. Please note that SP 800-63A does not require a biometric match of fingerprint samples from the background investigation and identity proofing events.
KBV cannot be used to satisfy the verification requirements for IAL2 or IAL3 in identity proofing. SP 800-63A Section 5.3.2 presents a detailed set of requirements for the use of KBV. The presence of this section might lead one to believe that KBV has an important role in verification of identity evidence at IAL2 and IAL3. Other identity proofing requirements greatly limit this role, however.
Evidence collection requirements at IAL2 and at IAL3 include at least one piece of Superior or Strong evidence. Section 5.3, Table 5-3 requirements for verification at Strong and Superior levels require that verification only be performed on the strongest piece of identity evidence. But Section 5.2.1, Table 5-1 limits the use of KBV to only Fair evidence. Together, these requirements mean that KBV cannot be used to satisfy the verification requirements for IAL2 or IAL3. KBV can, however, be used for supplemental evidence verification as part of a risk-based identity proofing evaluation.
As threats evolve, some authenticators become less reliable, so we established the notion of “RESTRICTED” to tag authenticators if they become of concern. We didn’t make this up: the NIST cryptography team has been using this approach for some time, and we like to be consistent with other NIST efforts so we don’t confuse our stakeholders. Implementing a RESTRICTED authenticator requires the agency to assess, understand, and accept the risk associated with that authenticator.
Therefore, the agency needs to:
Currently, authenticators leveraging the public switched telephone network, including phone- and Short Message Service (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator types may be added as additional threats emerge. Note that, among other requirements, even when using phone- and SMS-based OTPs, the agency also has to verify that the OTP is being directed to a phone and not an IP address, such as with VoIP, as these accounts are not typically protected with multi-factor authentication.
Risk-based or adaptive authentication systems evaluate a host of user, system, and environmental attributes; other such signals; and behavioral profiles to make an authentication decision. IP address, geolocation, time of day, transaction type, mouse movements, keystroke, and variances from typical usage norms are some of the signals used in these systems. These solutions do not currently count as a valid authenticator in and of themselves, as this information does not necessarily constitute a “secret,” and most solutions leverage proprietary ways of making an authentication decision. We are eager to discover secure, standards-based ways to execute these processes. However, until we have a good way to define the requirements to properly execute these approaches, “risk-based” and “adaptive” techniques are considered added controls to digital authentication. If you have ideas on how we can add these as acceptable authenticator types in future guidance, please let us know all about it!
Authentication intent is the process of demonstrating that an individual intended to authenticate. Establishing authentication intent – like entering an OTP from a device, inserting a smart card, or simply touching the device (known as proof of presence) – can act as a countermeasure against malware using the endpoint as a proxy for authenticating an attacker without the user’s knowledge. This makes it more difficult for the authenticator to be used for nefarious purposes outside the control of the legitimate user.
Verifier impersonation resistance places requirements on authenticators to reasonably thwart a phishing attack. Phishing attacks attempt to fool an individual into providing valid credentials to an attacker or a rogue site. At AAL3, SP 800-63B requires authenticators that use a verifier impersonation-resistant authentication protocol to prevent possible phishing attacks. There are a number of ways to do this, including various encryption protocols and digital signature technologies that bind the authenticator output to a specific protected channel. One example of a verifier impersonation-resistant authentication protocol is client-authenticated transport layer security (TLS). In this protocol, the client signs the authenticator output and earlier messages that are unique to the particular TLS connection being negotiated.
SP 800-63B Section 5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize.
Knowledge-based authentication (KBA), sometimes referred to as “security questions”, is no longer recognized as an acceptable authenticator by SP 800-63. This was formerly permitted and referred to as a “pre-registered knowledge token” in SP 800-63-2 and earlier editions. The ease with which an attacker can discover the answers to many KBA questions, and relatively small number of possible choices for many of them, cause KBA to have an unacceptably high risk of successful use by an attacker.
A similar technique, knowledge-based verification (KBV), is permitted for use in resolving identities and, with restrictions, in remote identity verification during enrollment and proofing. See SP 800-63A section 5.3.2 for details.
Overall, it is important to discourage the use of very common passwords, particularly those that are most likely to be tried in an online password guessing attack. Some passwords that meet requirements of common composition rules are in fact quite common (e.g., Password1!) while others that do not meet composition rules are not common at all.
The dictionary, or blacklist, should contain likely common passwords without particular regard to how they are composed. If passwords with repetitive characters meet that criterion, include them. However, as our forthcoming implementation resource center will point out, the blacklist should not include every conceivable password; that is likely to cause user frustration, which often leads to predictable patterns of behavior that attackers are likely to anticipate.
The reauthentication requirements session timeouts in 800-63B sections 4.1.3, 4.2.3, and 4.3.3 are intended to mitigate situations where a user’s device is left logged in but unattended, such as if the user walks away from a terminal. As AAL2 and AAL3 are intended to protect sensitive and potentially harmful data access, sessions at these levels have to be protected strongly. The timeout values are based on both past versions of 800-63 as well as common industry practices for accessing sensitive information.
There are other means of ensuring that the device is not used by a separate party, such as locking the device at the OS level and requiring local authentication for the subscriber to unlock. However, it is often difficult for a remote RP (relying party) to know the state of the subscriber’s device at runtime. In these cases, the session timeouts act as a reasonable control. If instead the RP knows that, for instance, the subscriber is using a managed system that requires screen lock by a system policy, the documented Digital Identity Acceptance Statement for the RP (see 800-63-3 section 5.5) can state that the risks addressed by short sessions are compensated for by other factors, and the RP can relax its session timeouts for such devices. Alternatively, an RP could manage most of the subscriber’s interactions at a lower AAL and switch to a higher AAL for sensitive operations. In these cases, the lesser-privileged session would be allowed to last much longer than the privilege escalation. Adopting these kinds of compensating controls are part of the RP’s risk assessment process and a matter of local policy.
Section 5.4 of 800-63-3 discusses the application of compensating controls and the assessment of risk in greater detail.
SP 800-63B Section 5.1.1.2 states in part:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
This text is a recommendation, not a normative requirement (i.e., “should” rather than “shall” in text). However, research has shown that composition rules do not significantly improve the security of selected passwords. Composition rules often have the opposite effect as users tend to avoid or shortcut the rules by making predictable changes, resulting in weaker passwords and less security. Instead, SP 800-63B requires the use of a blacklist of common passwords that are not acceptable for use. We do recommend increased password length as a key password security control, especially through encouraging the use of passphrases.
SP 800-63B Appendix A.3 contains a more detailed rationale for this recommendation.
NIST SP 800-63B does not allow the use of email as a channel for single or multi-factor authentication processes. This is specified in Section 5.1.3.1, Out-of-Band Authenticators:
[Authentication] methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.
Password managers offer greater security and convenience for the use of passwords to access online services. Greater security is achieved principally through the capability of most password manager applications to generate unique, long, complex, easily changed passwords for all online accounts and the secure encrypted storage of those passwords either through a local or cloud-based vault. Greater convenience is provided by the use of a single master password to access the password vault rather than attempting to memorize different passwords for all accounts. Most password manager applications offer additional capabilities that enhance both convenience and security such as storage of credit card and frequent flyer information and autofill functionality.
The compromise of the master secret to a password vault would require all passwords in the vault to be recreated. However, many password managers today provide two-factor capability and are designed in a way that cloud password services are not able to access the vault, even if compromised. Password managers contain much information that is valuable to cyber criminals, making them high-value targets, so securing these vaults is essential.
In SP 800-63B, NIST has not explicitly recommended the use of password managers, but recommends that verifiers permit the use of “paste” functionality so that the subscriber can use a password manager if desired. If using a password manager, subscribers should:
NIST SP 800-63B supports the use of biometrics as an authentication factor with some limitations. Biometrics may be used only as part of multi-factor authentication in conjunction with a specific physical authenticator (something you have). If biometrics are used in multi-factor authentication the following requirements apply:
The unlocking of a device through biometric match may not be considered to meet these requirements since it is generally not possible for the verifier to obtain any information on how, or whether, the device was unlocked.
NIST recommends that the biometric system implement Presentation Attack Detection (PAD). NIST is considering PAD implementation as a requirement in the future.
Please see SP 800-63B Section 5.2.3 for additional implementation guidance for the use of biometrics as an authentication factor.
Most authenticators using biometrics will function as multi-factor authenticators where the biometric unlocks a secret stored in the authenticator. A memorized secret (often a PIN) can also be used to unlock the same secret, as is common in many mobile devices.
NIST Special Publication (SP) 800-63B provides requirements, recommendations, and guidance for the use of memorized secrets (i.e., PINs, passwords) in authentication of digital identity. This guidance for memorized secrets is exclusively for human users. Specific guidance on memorized secrets for users and verifiers is contained in SP 800-63B Section 5.1.1. Memorized secret usability considerations (including password complexity and password change rules) are presented in Section 10.2.1. Also, SP 800-63B Appendix A, Strength of Memorized Secrets, provides additional guidance and explanation for the use of memorized secrets as an authenticator for digital identity.
Authentication of other than human claimants (e.g., APIs) is out of scope for SP 800-63-3.
Self-serve password reset requires authentication of the account owner (subscriber) in order to reset the password. Response to sets of knowledge-based questions is a form of knowledge-based authentication (KBA), and is not allowed to be used as described in FAQ B07 above and SP 800-63-3 Section 4.3.1:
Knowledge-based authentication, where the claimant is prompted to answer questions that are presumably known only by the claimant, also does not constitute an acceptable secret for digital authentication.
KBA for password reset would leave the account vulnerable to takeover.
Alternative authenticators for password reset include lists of look-up secrets and out-of-band device authentication. See NIST Special Publication 800-63B for more details for these authentication processes. If alternative authenticators are not available for password reset, then the subscriber’s identity will need to be re-proofed in order to gain account access. See SP 800-63B section 6.1.2.3 Replacement of a Lost Authentication Factor for additional details.
Yes. SP 800-63B Section 4.2.2 requires verifiers operated by government agencies at AAL2 to be validated to meet FIPS 140 Level 1. The use of a cloud service by a government agency, although perhaps directly operated by a commercial entity, is still operated on behalf of the government and does not modify that requirement.
The text recommends, but does not require, the use of a memory-hard function for password derivation.
NIST considers the security of the hash (one-way) function used in key derivation to be of primary importance, and therefore requires the use of an approved (thoroughly vetted) one-way function in key derivation. BALLOON is a memory-hard and time-hard algorithm that allows the use of an approved underlying one-way function, but unfortunately it has not been widely deployed. Other algorithms such as ARGON2 are memory- and time-hard, but do not use an underlying one-way function that has been thoroughly analyzed.
While PBKDF2 is time-hard but not memory-hard, it is so widely deployed that it is not practical (at this time, anyway) to introduce a requirement for a memory-hard key derivation function, so we have presented this as a recommendation (i.e. “SHOULD”).
The key derivation function is considered less critical than the one-way function that underlies it, so the specification is less prescriptive in this area and does not specify particular algorithms for key derivation.
800-63B section 4.2.2 states that “Authenticators procured by government agencies SHALL be validated to meet the requirements of FIPS 140 Level 1.” (emphasis added) The intent of the procured by language is to exempt user-provided (“bring-your-own”) authenticators from having to meet FIPS 140 requirements, particularly in the government-to-public use case. The FIPS 140 requirement applies only to authenticators purchased or issued by a government agency.
The requirement to compare prospective memorized secrets against a list of commonly used, expected, or compromised values in SP 800-63B Section 5.1.1.2, along with the rate limiting requirements in Section 5.2.2, is intended to blunt online guessing attacks against memorized secrets. It is intended that this requirement apply to the memorized secret as a whole, and not to substrings. If applied to substrings, this might make it more difficult to construct longer memorized secrets such as passphrases. Longer memorized secrets are almost always stronger than shorter ones.
Note also that the list of commonly used memorized secrets does not need to include a dictionary of words. Some words that are commonly used, such as ‘password’, should be included but since the intent is to prevent the use of the most commonly selected memorized secrets, the use of the entire dictionary is probably overkill, while some non-words such as ‘qwertyuiop’ and ‘12345678’ should probably be included.
Attribute references are partial attribute values, often represented as a boolean, given in response to an attribute query. Transmission of attribute references minimizes the personal information sent to a relying party (RP), enhancing the privacy of these transactions for individuals – think of the above instance of telling a RP whether a user is over a certain age as opposed to providing their full date of birth. An example that is not boolean is asserting an individual’s congressional district, rather than their full home address. An attribute value is the complete value for a given attribute, like full date of birth, and is in some cases needed by the RP.
We use the terms “reference” and “value” to effectively define methods of conveying user data and to explicitly set requirements for each. For example, credential service providers (CSPs) must provide support for both attribute references and values. We also ask that RPs, “where feasible, request attribute references rather than full attribute values.” More details can be found in SP 800-63C.
SP 800-63C Section 5.2 states “An IdP MAY disclose information on subscriber activities to other RPs within the federation for security purposes, such as communication of compromised subscriber accounts.” What does this mean?
This is our way of saying a provider can share information with federation participants to increase protections for the user and the overall federation network. In a federation, the goal is to share the minimum amount of data about a user to protect their privacy. But SP 800-63C enables an IdP or an RP to disclose information about subscriber activities to other participants within the federation for security purposes, such as communicating the detection of a potentially compromised subscriber account. This approach, typically called a “shared signals model” is becoming more common in the market.
For example, an individual may use an email account to manage their online shopping account. If the email provider detects an anomaly, such as a possible account takeover, they can send this signal to the bank. The bank can do whatever they want with this information based on their risk profile and business rules. In some cases the bank may ignore the signal. In others, or if the bank got similar signals from multiple providers in a short period of time, it might choose to notify the user of suspicious activity associated with their account and use additional security measures the next time the user, or malicious actor, attempts to log in. Sharing information across the federation can help stop hackers from gaining unauthorized access to participating services.
The highest federation assurance level of FAL3 is intended to be a forward-looking goal for very high value or very high risk situations, and as such takes some effort to get to. In FAL3, the IdP has to provide not only an assertion that’s been encrypted to the RP’s specific key (as in FAL2), but that assertion also needs to have a reference to a key. This RP has to ask the subscriber to prove possession of that key directly in order to reach FAL3, as this helps prove that the current user is in fact the one referenced in the assertion.
In practical terms, the easiest way to reach FAL3 with today’s technology is to use a certificate-based authentication (such as PIV) at the IdP and include a verifiable reference to the certificate’s key in the assertion. This reference could be the fingerprint of the key, or a set of fields that uniquely and globally identifies the certificate itself. When the subscriber logs in to the RP, the RP can then challenge the subscriber to present their certificate directly. Importantly, the RP only has to make sure that the certificate presented by subscriber is the one in the assertion; the RP does not have to validate the certificate’s chain or trust or process any of the attributes within the certificate. This approach has an added benefit of allowing the subscriber’s attributes to be provided within the federation protocol on an as-needed basis instead of forcing all attributes to be in the certificate itself.
The key referenced in the assertion is allowed to be the same as the credential that the subscriber uses to authenticate to the IdP, or it can be completely unrelated to the subscriber’s primary credentials. This flexibility allows for both cross-domain SSO style systems that use federation protocols as a bridge (like the PIV example above) as well as future systems where key references can be passed between the RP and IdP to create a higher assurance level than otherwise possible. With that in mind, future extensions to protocols like WebAuthn could allow a key to be presented at the RP but known and referenced by the IdP.
Note that just because FAL3 is the highest available FAL, it does not mean it’s always appropriate for a given application. See also: Q-4: Should I always use the highest xAL? How do I know which xAL to choose?
The term “authorization component” refers to an item that authorizes the RP to fetch additional information about the subscriber at runtime. This is provided to the RP alongside the assertion, but is separate from the assertion itself. It is used with an API providing additional subscriber information which can be optionally called by the RP when needed. The most common example of such an item is the OAuth 2 Access Token that is available in OpenID Connect alongside the ID Token assertion. The access token allows the RP to query the IdP’s User Information Endpoint, which is an API that serves subscriber attributes.
The authorization component could also allow the RP to access other APIs on behalf of the subscriber, which may or may not have anything to do with identity and authentication. It is common for an OAuth access token to be applied to a set of services related to the current user in addition to providing identity information with the OpenID Connect protocol. This layering allows for a powerful composition of services alongside identity.
We chose the term “authorization component” because the term “token” has an unfortunately overloaded set of definitions in this space and we wanted to avoid confusion. The definition of this term has been added in the second set of errata for 800-63C.
No, an assertion is not an authenticator as defined by SP 800-63-3. From the definitions, an assertion is:
A statement from a verifier to an RP that contains information about a subscriber. Assertions may also contain verified attributes.
In other words, it’s a verifiable statement from an authority that a particular user exists, has logged in, and has certain specific attributes. An assertion represents the authentication event that takes place at an IdP and conveys that information, in a verifiable fashion, to the RP. It is a message sent from the IdP to the RP, often directly.
On the other hand, an authenticator is defined as:
Something the claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity.
In other words, it’s something that the claimant has, either in their memory (something you know), in their physical possession (something you have), or in their person (something you are). This can be presented and proved by the subscriber when challenged by the RP, without intervention of another party. Conversely, in federation using a back channel presentation mechanism, the subscriber never sees or handles the assertion itself. The authenticator itself is established with the subscriber in such a way that they can use it many times over a period of time to authenticate to the RP. In contrast, an assertion is a time-bound message from the IdP to the RP about the subscriber, and many assertions are single-use within their system. Once an assertion has been processed, the RP needs not hold any reference to it.
In addition, a credential is:
An object or data structure that authoritatively binds an identity - via an identifier or identifiers - and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber.
The key mechanism here is the binding of the identity of the subscriber to a specific authenticator. In other words, a credential combines attributes about the subscriber with an authenticator. An example would be a certificate with subscriber attributes embedded within the certificate. An assertion may contain subscriber attributes, but it does not function as an authenticator, as discussed above.
All assertions at FAL2 have to be encrypted such that only the RP can decrypt the assertion’s contents. In most cases, TLS does not provide this level of protection and therefore does not suffice for the FAL2 requirement. In practice, FAL2 encryption is almost always accomplished by using a message-level encryption on the assertion itself, such as JSON Web Encryption of the ID Token in OpenID Connect.
For all assertions passed through the front channel, the TLS encryption protects only the links between the RP and browser, and browser and IdP. Since there is no direct connection between the IdP and RP, the assertion is available directly to the browser environment regardless of the status of TLS on the individual links.
For assertions passed through the back channel, the TLS encryption does protect the assertion from attackers. However, since the TLS connection is initiated by the RP, the IdP does not necessarily have a strong association between the identity of the RP and the encryption used at the TLS layer. If the RP uses mutually-authenticated TLS, and the IdP validates the RP’s certificate, and the RP’s certificate is strongly tied to the identity of the RP, then the TLS channel can be considered to be an encrypted protection of the assertion. Note that the assertion still needs to be signed by the IdP at all FALs.
Federation protocols as defined by SP-800 63C require an assertion to be sent as part of the federation transaction. This assertion is created as a result of the subscriber authenticating to the IdP, and in response to a federation request from the RP. The assertion is unique per federated login, tied strictly to the RP, time limited, and can carry a variety of attributes depending on what the RP needs and what it is allowed to see.
The certificate of a PIV card, on the other hand, is a static collection of attributes bound to a private key. When using a PIV for authentication, the same certificate is presented to each RP, with the same attributes embedded therein. This qualifies the PIV as a credential in the 800-63-3 model, but not as an assertion. A PIV certificate can of course be used to authenticate the subscriber to the IdP, which can then create an assertion that fits all of the required criteria.
Federation offers a number of benefits over accepting a PIV credential directly. The assertion can carry an identifier from the IdP that will be stable across different credentials for the same subscriber over time, and other attributes can be selectively disclosed to the RP depending on the RP’s needs and access. When the subscriber’s account is revoked, the subscriber will not be able to generate a new assertion at the IdP and the RP doesn’t need to check for credential revocation directly. Federation is also more flexible in allowing different types of client applications and APIs, many of which have a difficult time accepting and processing PIV credentials.
No, API access and any tokens used for API access are not covered by FAL. The federated assurance level is meant to cover the conveyance of identity information from an IdP to an RP through an assertion. This constitutes a federated login event to the RP. However, if that RP accesses an API, this is outside of the federated login. When that API dereferences or interprets the access token, this is not a login event since the user may or may not be present when the client is acting on the user’s behalf. Therefore, both of these aspects are outside the scope of SP 800-63C and the FAL designations.
For example, let’s say that you’ve got an email client that’s using an OpenID Connect (OIDC) login and getting an OAuth access token to call a cloud-based email API. The FAL covers the process of logging in to the email client itself, so that the email client knows who the user is through the ID Token. The FAL does not cover the use of the access token to call the email API, nor does it cover the process that the email API uses to figure out which user is represented by the access token.
Digital identity wallets do not normally fulfill the requirements to be considered an IdP by the Digital Identity Guidelines.
There has been interest in recent years in using applications to store cryptographically protected material on a user-carried device, a practice sometimes referred to as a digital identity wallet. In their most common applications, digital identity wallets act as queryable personal data stores, collecting attributes from a variety of sources and presenting these attributes directly to relying parties.
In most distributed scenarios that digital identity wallets are applied to, the RP’s trust in the attributes tends to come from the ultimate sources of the attributes, not from the wallet itself. This is in contrast to the IdP model presented in the Guidelines, where the RP’s trust in the attributes stems from its trust in the IdP asserting those attributes in a federation transaction. From the perspective of the Guidelines, the IdP is the source of the attributes. The IAL and AAL for a given federation transaction are applied to the entire account being presented, with any attributes asserted as being a part of that account.
Furthermore, while the IdP model in the Guidelines does allow for presentation of attributes through an identity API in addition to being present in the assertion itself (see Q-C8 for details), even in these cases, the identity API is assumed to be under the control of the IdP and inherits its trust from the IdP. Use cases involving independent attribute providers, attribute metadata (including provenance), and distributed attribute models are outside the scope of the Guidelines.
That said, it is technically possible for a digital identity wallet to act as an IdP. While OpenID Connect and SAML are the most common federated identity protocols in use today, the Guidelines allow any protocol that meets the requirements outlined in the Guidelines to act as a federation protocol. Similarly, while a web-hosted server is the most common deployment for an IdP, the Guidelines do not assume any particular deployment model for IdPs. Given that the definition of IdP does not assume a publicly deployed web service, a digital identity wallet could serve the function of an IdP as long as it fulfills all the requirements laid out in the Guidelines. Namely, the wallet would need to create a signed assertion (which still needs to meet all the general assertion requirements) and somehow transfer that assertion to the RP over a network using either a front-channel or back-channel presentation mechanism. The RP in turn would need to be able to validate the assertion’s signature and contents, as well as determine that the IdP is a trustworthy party for generating the assertion. There are numerous methods for establishing an IdP-RP trust relationship discussed in the Guidelines, and any of these could be applicable to trusting assertions from a digital identity wallet style application. However, these kinds of trust relationships are uncommon in the kinds of networks that digital identity wallets are designed for, with each user carrying their own independent wallet.
In the end, while it’s technically possible for a wallet to act as an IdP, to be useful in practice it would need to truly act in that role. This includes the need for RPs to establish trust for assertions and attributes coming from the wallet as well as the wallet’s ability to present these assertions and attributes to the RP.
If identity attributes/PII are sent over the back channel, either in the assertion or in a separate request, then FAL2 is not required in order for the information to be sufficiently protected as stated in the implementation guidelines. FAL1 should provide sufficient protection in this instance because the PII is not exposed to untrusted third parties, such as the browser. The requirements describing situations in which FAL2 needs to be applied can be found in Section 4 of SP 800-63C.
The goal of FAL2 as currently defined is to provide protection against disclosure of sensitive personal information contained within the assertion as well as to provide stronger audience restriction of the assertion presentation. With front-channel presentation, this protection requires assertion encryption as presented at the conclusion of the decision chart. However, with back-channel presentation, the inclusion of identity attributes/PII in the assertion does not lead to the same vulnerability surface as the assertion is not exposed to unintended third parties such as the subscriber’s browser. Furthermore, PII can be protected from disclosure by simply not including it in the assertion at all and instead relying on an identity protocol alongside the assertion, such as the OpenID Connect standard UserInfo Endpoint protected by an OAuth 2.0 access token.
The FAL selection chart, found in Figure 6-3 in Section 6.3 of SP 800-63-3, provides more stringent advice than what is required by the normative statements in the guidelines. However, the selection chart is intended as complementary advice and does not provide normative requirements on its own. Since the FAL selection chart provides advice above what is strictly required by the text, this inconsistency will be addressed in a future version of the guidelines.
For additional information, Section C.2.3 of the SP 800-63-3 Implementation Resources goes into more detail on selecting and reaching FAL2.