Cisco Blogs

NSTIC Strategy Released

April 20, 2011 - 2 Comments

Last June, I blogged about a draft of the National Strategy for Trusted Identities in Cyberspace (NSTIC) that had been released for public comment. This past April 15, the finalized NSTIC strategy document was released at an event at the US Chamber of Commerce.

For those of you that aren’t already familiar with the NSTIC, it is a US government-facilitated initiative that seeks to simplify and strengthen user authentication and to provide trustable assertions about principals in online transactions through the creation of an ecosystem that includes identity and attribute providers. More information is available at the NIST NSTIC website, particularly the animation video. NSTIC seeks to improve trust in use in the Internet and to enable new uses that depend on trusted attributes and higher assurance transactions.

Although the release of the NSTIC strategy is occurring about six months later than had originally been hoped, this finalized version is a great improvement over last summer’s draft. It at least partially addresses several of the unanswered questions and issues that I had at that time:

  • Business models: The strategy places greater emphasis on the need for the development of sustainable business models for the participants in the Identity Ecosystem. They set a benchmark of 10 years for the model to be self-sustaining.
  • International structure: The strategy now commits to collaboration with international governments, emphasizing international (and industry-led) standards, and cites NSTIC’s role in international trade. While the details are yet to be worked out, the commitment is spelled out to a much greater extent than in earlier versions.
  • Governance structure: The governance structure of the Identity Ecosystem is not further defined in this version, and now referred to as the “steering group” (perhaps to avoid confusion between the words “governance” and “government”). However, three workshops are planned for the late Spring time frame, and the subject of one of those is governance, so the need for better definition of this has definitely not been forgotten.
  • Low-value transactions: I had been concerned that there was an over-emphasis on high value applications, such as financial and health care, requiring high security authentication, and not enough attention paid to low value transactions that form the bulk of everyday usage. The NSTIC strategy now mentions transaction friction [Benefits for the Private Sector] and the existence of “a diverse and heterogeneous environment of providers and methods of authentication” [Guiding Principles: Secure and Resilient].
  • Technology mandates: The strategy now avoids calling out specific technologies, like DNSSEC, IPSec, or BGPSEC, which may or may not be directly relevant to the establishment of the Identity Ecosystem.

The examples, primarily in the “Envision It!” sidebars, are much improved over those in the draft. Some of the examples had led to the incorrect conclusion that the government was trying to set itself up as an identity provider. The use cases are now more meaningful as well. For instance, one of these examples (#5) describes a user deciding which credential to use for a new application they’re enrolling with, which emphasizes the fact that users aren’t limited to one identity provider, just as they’re not limited to doing business with one bank.

There are, of course, a few things that I would have done differently. The strategy places a lot of emphasis on the role of state, local, tribal and territorial governments; this might be misconstrued as an unnecessary governmental intrusion. While these levels of government may have important roles as attribute providers and relying parties, their role in the identity ecosystem has many similarities to that of the private sector.

There is also a bit of confusion about anonymity and pseudonymity, especially at higher levels of assurance. This derives from the fact that the demarcation between roles of identity providers and attribute providers, a somewhat new concept in NSTIC, hasn’t been defined sharply enough. I will be writing more about that problem and possible solutions in a future blog post.

It’s important to recognize that this is a strategy document, so it doesn’t answer all the questions. There will be three workshops to start to work out the details, and much more after that. There is a lot of work to do.

I am planning on writing several more blog articles on various topics relating to NSTIC. Look for them in the coming weeks.

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. JMA –

    Thanks for your comments.

    NSTIC identity ecosystem participants (identity providers, attribute providers, etc.) will operate under an accreditation framework, so that a participant that is breached or otherwise not performing securely can have its accreditation revoked. The experience from the SSL issues is very relevant: revocation needs to be a real option. It’s important that both the technology (revocation protocols) and practicalities (can’t have any participant that is “too big to fail”) all need to be considered to make this really work.

    You do have the option to have more than one identity provider in NSTIC, just as you can have more than one credit card. The separation between identity providers and multiple attribute providers also is a separation of privileges. I’ll be writing more about this sort of separation in future installments.

  2. Hello Jim, interesting post 🙂

    I may have missed some points but it looks like this strategy moves the problem to the identity providers if I understood correctly. Nowadays, SSL is in the spotlight: certificate authorities hacked (see Comodo group incident) = the whole chain is dead. Without getting into privacy issues, how having NSTIC identity providers with that level of control is different? In my opinion, the strategy will work until one of those identity providers gets hacked, then back to square one…

    Also, while remembering a whole set of random passwords has its drawbacks, it is powerful at the same time: if the service provider I am using is compromised, not all my service accounts are compromised, dramatically reducing the collateral damage.

    I do not know how it can be improved, maybe separating key privileges would be a good start: an identity provider would be able to create an identity OR would be able to verify an identity OR would be able to revoke an identity but would never be able to perform more than one of those tasks.. at least so that key operations are not related to a single entity in charge of everything the system security is built on.