Cisco Blogs

Adapting Levels of Assurance for the NSTIC

- May 19, 2011 - 5 Comments

This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.

One of the goals of the National Strategy for Trusted Identities in Cyberspace (NSTIC) is to support a wide range of use cases. These might include everything from low-value purchases to making adjustments to critical infrastructure, like power systems, where someone might get hurt if an unauthorized action takes place.

The level of confidence in the validity associated with an identity is referred to as Level of Assurance (LOA). In a specification referred to as M-04-04, the US Government has defined four LOA levels, from LOA 1 (little or no confidence) to 4 (very high confidence). They also define the minimum LOA that should be applied in various use cases based on the type and severity of harm that might occur if a user is misauthenticated.

The National Institute of Standards and Technology (NIST) authored a companion specification, Special Publication 800-63, defining the corresponding types of authentication and identity proofing requirements (documentation required at enrollment) that are appropriate for each of the four LOAs. A very brief summary of the requirements is:

  • Level 1: Basic challenge-response methods
  • Level 2: Single-factor authentication; basic identity proofing
  • Level 3: Multi-factor authentication; extended identity proofing
  • Level 4: Multi-factor authentication with “hard” token; extended identity proofing

[Note that the very common practice of sending passwords in the clear doesn’t fit anywhere here. A lot of what’s currently being done can be thought of as “Level 0”.]

The underlying principle here is that authentication requirements should correspond to the risk or value of the resultant use. While it’s clearly inappropriate to use a weak form of authentication for a high-risk transaction, it’s also undesirable to require a high level of assurance, which usually involves more overhead, for low-value transactions because of the “friction” it introduces. We don’t want to discourage people from doing things on the Internet by imposing onerous authentication requirements everywhere.

When these specifications were written several years ago, the NSTIC model of separating the role of identity (credential) providers and attribute providers hadn’t fully matured. It has been common practice for credentials to carry a number of attributes, such as the user’s name, as well as cryptographic information required for authentication. As a result, SP 800-63 requires various types of identity proofing (verification of physical credentials at enrollment time) to be associated with the issuance of credentials at LOA 2 and above. However, the wider applicability of NSTIC includes use cases requiring pseudonymity, and that requires the separation of authentication and attributes.

An alternative way to look at this is to consider the association of the user’s name and other identifying characteristics to be attributes rather than elements of the user’s authentication. Identity proofing requirements then would be associated with the user’s enrollment at an attribute provider, which would occur after the user has been issued authentication credentials.

The effective level of assurance for a transaction then becomes a composite of several things. It depends on the LOA of the user’s authentication, and the LOA reflecting the practices of the credential provider. It also depends on the LOA of the attribute (how thorough identity proofing was performed), how securely it is bound to the authentication credential, and the LOA reflecting the attribute provider’s practices. The low-water mark, or minimum of these LOA values, becomes the effective LOA of the identity.

There is currently some discussion with NIST about reflecting this distinction more completely in SP 800-63, which is currently being revised.

The ability of users to choose their identity and attribute providers is important in the NSTIC identity model. The ability to separate these roles completely and assign responsibility for identity proofing to attribute providers enables many additional entities to participate as identity providers. Giving users more ability to choose providers they trust will enhance user acceptance and, ultimately, enhance the value of the NSTIC.

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Jim, Should we consider the point that the higher levels (e.g. 3 or 4) is not only extended proofing but the binding of proven identity to the token (often using biometrics) during the credentialing process and as a matter of course in the registration of the identity. This is where some of the basic identity attributes cannot easily be offloaded to a third party without complication. Really great post and important topic. Sal

  2. Sal, At the time the attributes are bound to the identity (I think this is what you refer to as the "registration of the identity"), the user would need to authenticate at the highest LOA that they want to use at the time of the registration. I don't see any reason why the issuance of the credential would require in-person participation, even with biometrics, if a token can be bound to an individual only once, it doesn't matter who it is until it gets bound to some attributes. Mechanisms for recovery of lost credentials still require a bit more thought, but could involve the transfer of identifying information back to the credential provider only for that purpose. Thanks for your thoughts!

  3. Jim, All three NSTIC articles have been well written and very informative, thank you. Auston Holt

  4. I'm afraid that the LOA paradigm (and I use the P word deliberately, for what we're talking about is a world view that has deeply influenced identity management thinking far and wide) is based on a risk management methodology designed for internal organisation use, and was not originally intended to be portable. This means that LOAs are not actually interoperable. One IdP's claim that its identities are at level LOA 3 for instance, will not automatically jive with an RP's assessment that their transactions are LOA 3. The quaternary (four level) LOA is classically calculated by gauging the likelihood of threat events and the severity of those events, and combining likeihood and severity to produce a risk level. For example, the Australian Government guidelines for determining Assurance Level recommend gauging Severity as one of {Insignificant, Minor, Moderate, Major, Severe} and Likelihood as one of {Rare, Unlikely, Possible, Likely, Almost Certain}. All well and good - seems intuitive. Except that severity is a judgement call. Some risks relate to life and limb, some are purely financial, and others are political or reputational. Moreover, risk is relative and varies between organisations. So a potential loss of $100,000 might be Severe to a small business but Minor to a large bank. The Risk Management standards on which LOAs are based were written to provide organisations with the means for organising their internal thinking and approaches. Modern risk management entails systematically tabulating threats, calculating resulting risks, selecting mitigations, and agreeing to acceptable residual risks on the basis that no security is ever perfect. This methodology provides visibility of risk management decisions, and benchmarks for monitoring performance over time. The reality is that these risk management methods were devised for internal use. They're all relative. One organisation might assess a particular threat (say the accidental loss of a hard drive, or an intrusion by a hacker) as a "Low" risk while another can see the exact same threat as a "High" risk. Risk levels do not translate between organisations. And therefore the LOAs that are built into NSTIC and most other contemporary IdM concepts are not interoperable. The devil is always in the detail. I find it inconceivable that any RP carrying out high risk transactions (say medical prescriptions) is going to be able to make sound decisions to accept any old LOA 3 or LOA 4 identities without qualification. This means that the decision to accept any given identity will have more to do with the precise meaning of the identity (say 'this is a registered medical doctor in the state of XYZ') and the exact IdP (e.g. Medical Registration Board of XYZ). For anything other than level 1, I am afraid that LOA is going to be academic.

    • Steve, It's true that both of the specifications I cited (M-04-04 and SP 800-63) were designed for internal organization use, that organization being the US Government. It's up to the Relying Party to determine the LOA they require: what constitutes a "high" risk for them, for example. To the extent that risk-sharing takes place between the participants (i.e., with the Identity Provider and Attribute Provider(s)), the amount of liability these parties take on may depend on the LOA requested, as may the cost of the transaction to the Relying Party. If the Relying Party misjudges the risk of the transaction, they either take on more risk or more cost (and transaction friction). I would also look to the accreditation framework to set some further standards to make the LOA paradigm more interoperable. There will probably be some residual variability in what LOA is used for specific transactions, but I don't see this as invalidating the concept of using LOA between organizations.