Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

NSTIC Pilot Common Considerations 3: Risk Assessment Methodologies and Authentication Strength

Last September, NIST awarded grants to five organizations to stand up NSTIC pilots focused on advancing the NSTIC vision, objectives and guiding principles, demonstrating innovative frameworks that can provide a foundation for the Identity Ecosystem, and tackling barriers that have, to date, impeded the Identity Ecosystem from being fully realized. This blog is the third in a series that focuses on some of the common questions that have emerged as the pilots have moved forward.  Given that NSTIC relies on a multi-stakeholder collaborative process to advance the Identity Ecosystem, our hope is that these blogs on pilot “Common Considerations” will kick off discussion and collaboration on these questions.  The two related Common Considerations discussed in this blog are:

  1. There is a lack of standards regarding Relying Party’s (RP’s) risk assessment processes and thereby the required strength of identity needed for a transaction.   Current material relies heavily on OMB 04-04 and NIST SP 800-63, which is only directly applicable to U.S. Federal government use cases – it is not clear how the material in these reference documents should be extended to non-federal use cases.
  2. Once an RP has stated the required assurance strength, there needs to be a method to quantify the confidence in an asserted identity, both in terms of identity proofing and identity authentication.   A model needs to be created to objectively state the confidence in asserted attributes, and the confidence in an authentication mode, such as tokens, passwords, biometric technologies, etc.   It would be helpful to compare these methods with the authentication tables in NIST SP 800-63.

As noted in the Terminology blog of this series, the required degree of confidence in an individual’s identity by a Relying Party is based on their risk analysis and business practices; alternatively, it may be pre-determined by a regulatory environment (for government, healthcare, financial, or other industries).   It was also discussed in the Trust Frameworks blog that Communities of Interest are forming with collective viewpoints on operating principles, including risk assessment schemes.   This blog explores some emerging themes around risk assessment and authentication strength.   The degree of confidence in the individual’s identity is often expressed as the required “Level of Assurance”, although this term evolved out of specific federal risk assessment practices.   The level of assurance defines the level of confidence in identity required by the Relying Party.   It is also used to express the level of confidence provided by Identity Providers, Attribute Providers, or by an Intermediary (by combining inputs from Identity and Attribute Providers).   Thus, the success of identity ecosystems is based on parity between the expressed requirements of Relying Parties (RP’s) and the asserted or proven capabilities of Identity/Attribute Providers (IP/AP’s).   As mentioned above, to date, such RP requirements have largely been expressed based on federal documents such as OMB-04-04 and NIST SP 800-63, and IP/AP capabilities have been accredited under the auspices of the corresponding program: the FICAM Trust Framework Provider Adoption Process.   We believe that a broader ability to achieve demonstrable parity across the various actors in commercial identity ecosystems, and in the context of a range of industry sectors, is critical to the future success of identity ecosystems.   We anticipate that the IDESG will create a voluntary, consensus framework for accrediting a wide range of identity ecosystem components for commercial and federal industry sectors, incorporating existing material where possible, but also leveraging the fact that it is not constrained by a particular marketplace.   To explore this topic further, we think that it is beneficial to look at both sides of this equation. Risk Assessment As the number of industry sectors that depend on identity services increases, it is imperative that some degree of common understanding regarding risk assessment evolves; otherwise a fundamental component of interoperability across operators is missing.   If relying parties and other operators assess identity risks in different ways: they are unable to articulate their requirements using a common lexicon; deployments end up being done in an ad hoc manner; and relying parties ultimately have to make decisions about how to combine identity attributes to mitigate their risks.   This places more of an onus on relying parties than is necessary – leading to higher integration costs and potential liability, which will inhibit the uptake of identity solutions and overall success of the ecosystem.   Further, a lack of a coherent and mutually-recognizable risk assessment methodology will likely limit the adoption of identity solutions by new industry segments.   For example, the recently-issued Executive Order and associated Presidential Policy Directive-21 mandates the development of a Cybersecurity Framework for use by commercial and federal critical infrastructure operators.   Unless a clear and concise methodology is available to determine risk and potential consequences of identity breaches, new sectors may be apprehensive about incorporating identity technologies, which are essential to underpin any cybersecurity strategy. There is no doubt that different industry segments have different ways of assessing risk, and that risk related to identity needs to sit alongside other risk factors.   There is also no doubt that having finer granularity in the required identity assurance than the “standard” four levels provides more implementation flexibility, but it also inhibits interoperability in terms of Identity/Attribute Providers’ ability to provide pre-packaged solutions across a wide range of Relying Parties. As more and more industry sectors such as healthcare, financial, education, aerospace and defense, and pharmaceutical, integrate identity technologies, we think that it would be insightful for the IDESG to continue solicitation of discussions with representatives from each of the sectors with a view to harmonize as best possible the various methodologies used to assess identity risk. Authentication Strength In terms of mitigating identity risk, there are an increasing number of available authentication methods, as well as ways and means of combining them.   For example, a growing number of authentication technologies are being made available on mobile phones, so a combination of: device possession, location, out of band communications and biometric technologies can be used in a particular scheme.   Recall that the ability for an individual to assert a claim of identity in support of a transaction depends on: the underlying confidence that a set of attributes ties them to their actual identity (identity Proofing), and the level of confidence that the individual is actually that person at the time of transaction (authentication).   The capabilities of identity proofing and authentication have historically been provided by a single entity.   However, there are an increasing number of architectural models and commercial forces that are driving more towards a componentized model.   As this occurs, the binding mechanism between identity proofing and authentication becomes ever more important.   The binding mechanism needs to be acceptable at the point of transaction, so that the relying party has sufficient confidence that they are providing service to the appropriate individual.   The mechanism and type of binding used to create a credential will also affect the potential interoperability, or recognition, of the credential by other subsequent relying parties. Standardization efforts in identity proofing are ongoing, for example, NASPO continues its work towards an ANSI standard on “Minimum Standards for Proof and Verification of Personal Identity”, and the ISO efforts in ISO/IEC SC27 WG5, recently led to the production of a first draft of ISO 29003: “Identity Proofing”.   The ICAO New Technologies Working Group has also previously done work on “Evidence of Identity”.   The other two aspects of a transactional authentication: that of the authentication mode and the binding between proofing and authentication still requires further development. Most of the authentication work today tends to migrate towards equivalence with NIST 800-63-1, specifically with Table 7.   However, as they types of authentication methodologies increases, as does the range of platforms on which they are used, it would be beneficial to measure and catalog the various technologies used and provide recommendations for how they can be combined to support strengthened identity authentication.   We see this as an extension of the previous work in SP 800-63-1, and something that is required as identity authentication is used increasingly in commercial applications.   Providing a well-characterized set of authentication methods and platforms will provide more assured guidance for relying parties, thus improving the uptake of identity solutions. The last major piece of the authentication puzzle as we see it is the binding between identity proofing and authentication components.   As mentioned previously, these capabilities were historically undertaken by a single entity.   However, the flexibility of systems is driving more towards separated components that can be supported in various parts of the ecosystem.   For example, a relying party may generally use external authentication methods, but for some transactions, is required to increase the level of confidence that they have in an individual through the use of compensating factors (either on a transactional basis, or on a more permanent basis as contemplated by the OASIS Technical Committee on Trust Elevation).   This can easily be achieved in a well-characterized system by the relying party invoking some additional identity provider/attribute providers for the transaction.   So far, the concepts relating to the binding of identity components have been discussed and developed in the Kantara Initiative, and observed by our GSA colleague Anil John in his series of blogs.   We believe that it would be instructive for the IDESG to consider the emerging range of authentication technologies and how they can be combined to provide an overall transactional strength of identity assurance. We hope that this blog post will catalyze further discussion around these topics within the IDESG, and that the IDESG will look to define recommendations to attempt to overcome these challenges...   Initial questions that we’d offer to stakeholders include:  1)      How much should the IDESG facilitate sector-specific identity risk assessment discussions?   Would the IDESG consider hosting sector-specific roundtables? 2)      In which IDESG Committees should risk assessment be discussed?   Security, Standards, Sector-Specific Committees? 3)      How granular should the levels be within identity risk assessment methodologies?   Four levels?  More? 4)      Can the wide range of emerging authentication types be “cataloged” to meet specified risk-mitigation requirements? 5)      What accreditation schemes are emerging to assess authentication strengths of particular modalities and on specific platforms? 6)      How does the IDESG ensure that accreditation schemes are aligned with international efforts, such as those in ISO/IEC SC’s 27 and 37? 7)      Should levels of assurance be mapped similarly to 800-63, or is another scheme desirable? The IDESG established a forum for further discussion regarding these and other related topics at the following location:


In Canada (federal government) we have standardized our assessment approach and have formalized the methodology in our policy instruments. All federal departments must use this assessment methodoligy. We have used the many of the concepts as originally posed in OMB M04-04 and NIST SP 800-63 but we have made some key distinctions. We have addressed many of the issues above and I would be happy to provide anyone with further information.

Add new comment

Enter the characters shown in the image.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Please be respectful when posting comments. We will post all comments without editing as long as they are appropriate for a public, family friendly website, are on topic and do not contain profanity, personal attacks, misleading or false information/accusations or promote specific commercial products, services or organizations. Comments that violate our comment policy or include links to non-government organizations/web pages will not be posted.