ID management: A matter of trust

People have countless reasons to support good digital identity management. When the federal government is involved, however, a complex challenge gets even trickier.

If the federal government could issue a standard digital identity card to members of the general public as it has for its employees, then fielding that critical tool for more secure and cost-effective e-government and e-commerce would be much simpler — and probably happen a lot faster, too.

But deeply rooted opposition to a national identity card, magnified by concerns about the potential for easy government tracking and surveillance of individuals, rules out the use of government-issued digital IDs, at least for now.

In April 2011, the Obama administration launched a plan called the National Strategy for Trusted Identities in Cyberspace (NSTIC) to encourage the private sector to develop, with federal support and input, online ID and authentication systems that people could use and government agencies, other organizations and commercial players could accept without each needing to create their own vetting systems.

When the plan was launched, Commerce Secretary Gary Locke said, “Working together, innovators, industry, consumer advocates and the government can develop standards so that the marketplace can provide more secure online credentials, while protecting privacy, for consumers who want them.”

Although NSTIC is intended to act as a technical stimulus plan for greater e-government and national e-commerce activity, it also meshes with the administration’s push to harmonize and accelerate agencies’ development of other identity management capabilities, such as using government employee smart cards to control access not just to buildings but also to agencies’ online systems.

At this point, NSTIC supporters are making headway, though perhaps not in a headline-grabbing way. Earlier this month, the Identity Ecosystem Steering Group, a federally supported committee led by the private sector that will guide creation of NSTIC-style systems, met for the first time in Chicago to hash out plans for addressing privacy, standards, usability, contracts and other key components.

And the National Institute of Standards and Technology, which runs the government’s NSTIC program office, was scheduled to award up to $10 million for several private-sector identity management pilot projects, though no award decisions had been made as of press time.

There is no doubt that NSTIC faces many challenges, and its eventual success is far from certain. The critical hurdles include getting competitors — such as Google, Microsoft, Verizon, AT&T and others — to cooperate on the development of interoperable solutions. Then the public has to embrace and learn how to use those new online credentials.

For their part, government agencies must build a business case for funding the systems that allow them to accept the externally created IDs, which is not a given considering the spotty track record of similar initiatives.

“NSTIC has the dual challenge of adoption within the government and adoption within the private sector, and that’s a tough row to hoe,” said Don Thibeau, executive director of the OpenID Foundation and chairman of the Open Identity Exchange, two industry groups coordinating the technologies and policies, respectively, used in the nascent identity management ecosystem.

Thibeau said there are four key public-facing agencies whose adoption of NSTIC-style capabilities is critical for attracting the support of other government agencies and the private sector: the Internal Revenue Service, the Social Security Administration, the Department of Veterans Affairs and, to a lesser extent, the Centers for Medicare and Medicaid Services.

“One would hope those agencies would be a hotbed of discussions and pilots and experimentation and engagement, but we’re not quite there yet,” Thibeau said.

Making the case for ID management

The recent theft of millions of user passwords from the business-focused social networking website LinkedIn is just the latest example that highlights the shortcomings of a common approach to security and identity management. The big worry is not that a bad guy will change a person’s job history in a LinkedIn profile. The fear is that because people tend to use the same password for multiple sites, the identity thief could gain access to other sites with more sensitive and valuable information.

“If you look at a lot of the breaches today, they continue to be due to the fact that user names and passwords are pretty weak and easily compromised,” said Gordon Hannah, a principal and federal identity management leader at Deloitte and Touche.

Maintaining multiple passwords is inconvenient for end users and requires every website owner that wants to authenticate the identities of its users to build and manage its own identity-proofing and authentication system.

Unfortunately, that costly and redundant approach is the predominant model in government for both internally oriented networks and public-facing websites — a pattern made clear by Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance Version 2.0, issued in December 2011.

The many flavors of identity credentials

The better approach, and the one prescribed by the FICAM guidance, shifts identity management responsibilities from stand-alone applications to an authoritative and trusted identity management network that acts as an enterprisewide service.

In that scenario, a person would get a single digital identity credential that he or she could use for multiple purposes. If the person is a federal employee, the credential provider could be a government agency, as with the civilian smart cards required under Homeland Security Presidential Directive (HSPD) 12 or the Defense Department’s Common Access Cards. If the person does not work for the government and NSTIC is successful, the identity provider could be a private-sector entity such as a bank, e-commerce site or health care network, to name just a few examples.

The National Institutes of Health began working on those kinds of trust network capabilities before NSTIC arrived on the scene. NIH’s iTrust program has already shown the value of capitalizing on externally issued credentials for use on multiple websites. In one initiative that launched in June 2010, the number of people using externally issued credentials to access NIH sites such as PubMed has grown to more than 72,000, resulting in a cost avoidance of about $3 million for fiscal 2011 through 2015. Those savings will result from not having to manage user IDs and passwords for about 50 systems.

One of the authentication methods that PubMed supports allows users to easily sign into the site if they already have a Google account. When a person signs up to use a Google service such as Gmail for the first time, he or she is actually creating an online credential based on OpenID. Under the General Services Administration’s FICAM process, OpenID credentials are already approved for certain types of government use. Many companies also support the open standard, including AOL, Yahoo, Symantec’s VeriSign and others.

There are also stand-alone OpenID providers, such as myOpenID or Symantec’s Personal Identity Portal, although use of those services has generally not yet spread beyond the technology and developer communities. And because OpenID is an open-source project, any organization or individual can in theory become an OpenID provider.

That is the type of ecosystem that NSTIC envisions — one in which a nongovernment entity can issue an OpenID-compliant credential that a government agency can accept as the so-called relying party. Trust framework providers are responsible for ensuring that the identity providers meet agreed-upon standards for issuing identity credentials and sharing appropriate information, thereby allowing the relying party to confidently accept the credentials.

But OpenID is only one of the potentially many flavors of identity credentials that could co-exist in the NSTIC ecosystem. Other credentialing techniques already approved by GSA include Identity Metasystem Interoperability 1.0 and Security Assertion Markup Language 2.0. NSTIC also seeks to encourage the private sector to produce a rich set of credential options for individuals, businesses and government that meet varying levels of privacy and security assurance needs.

How all the players and roles will shake out is difficult to predict at this point given the diversity and complexity of the activity, experts say.

For example, SSA deployed a new feature on its public website in May that allows eligible people to set up a “my Social Security” account to access their Social Security earnings and benefits information online. To ensure that website visitors are indeed who they say they are, the SSA site uses an identity proofing service called Precise ID from the credit risk management company Experian. Potential users must correctly answer several questions related to information in their financial history that Experian can access.

The identity proofing and authentication process is only used on the SSA website; it does not currently culminate in the issuance of a credential that could be used on other websites, said Philippe de Raet, Experian’s senior director of public-sector strategy. SSA officials did not respond to several requests for comment.

However, Experian’s Precise ID achieved recognition last month for meeting FICAM’s criteria for identity proofing at Assurance Level 3, according to the company. That means that at least the proofing component of the SSA vetting process is ready to play in an NSTIC-style environment of trusted networks if the agency chooses to become a credential provider that issues IDs other agencies could rely on.

To some observers, SSA’s new authentication capability might look like another one of the application-specific, stand-alone identity management systems that NSTIC and FICAM aim to eliminate, but Hannah disagrees with that view.

“I think it’s an important part of the foundation,” he said. “They are in essence becoming an identity provider.”

The privacy challenge

NSTIC-style credentials are intended mainly for transactions involving sensitive information such as financial or health records. Therefore, people would not be obligated to get one, and they could still surf the Web anonymously.

However, an NSTIC-style system of trust networks could increase privacy on the Web — for example, by having people’s identity authenticator confirm that they are old enough to use an age-restricted website without the need to share their exact birth date.

“One of the key focus areas of NSTIC is to put individuals in control and allow them to limit the amount of information getting shared and prevent information from getting shared without their concurrence or knowledge,” Hannah said.

Credential providers would need to offer individuals easy-to-understand tools for managing privacy settings as their credentials are shared with other relying parties. That’s not as easy as it might sound, as some Facebook users know.

The popular social network site lets users log into other websites with their Facebook credentials. However, if users aren’t careful about their privacy settings, the slideshow they viewed of celebrities behaving badly or the embarrassingly inappropriate words they played on Words With Friends could show up on a status update shared with all their Facebook contacts.

User education also needs to improve in other areas. Millions of people already have an OpenID credential if they use Google, Yahoo or Flickr, yet they might not realize it. It is hard to manage privacy settings if you don’t understand or even know you have them.

Because of such issues, not everyone is convinced that NSTIC’s model of private-sector leadership is the best way to ensure privacy.

“Identity technologies may be used for profit or to preserve privacy but rarely both,” wrote Aaron Titus, chief privacy officer and general counsel at security and privacy software developer Identity Finder, in a blog post about NSTIC. “While we’re concerned about the unsolved technological hurdles, we are even more concerned about the policy and behavioral vulnerabilities that a widespread identity ecosystem would create.”

Titus and other security experts also point out that single credentials used for such high-value transactions would be irresistible targets for hackers.

Slowly building trust

As far as the government side of online transactions goes, agencies have made mixed progress on their internally oriented identity management initiatives. How easily they will get onboard with NSTIC and start accepting externally created credentials remains to be seen.

DOD’s Common Access Card is used for many physical and logical access applications, including some involving the highest sensitivity levels. Meanwhile, civilian agencies are still wrapping up the initial phase of issuing HSPD-12 smart cards. As of Sept. 1, 2011, 91 percent of federal employees and 81 percent of contractors had the cards.

Some agencies now use the cards to control entry to government facilities. But they have made much less headway in using the cards for access to government networks and online applications or accepting cards issued by other agencies, according to the “Personal ID Verification” report the Government Accountability Office issued in September 2011.

The biggest stumbling blocks are agency priorities and budgets, not technical issues, according to the report. White House officials are doing what they can to advance the efforts short of allocating additional money. The Office of Management and Budget issued memorandum M-11-11 in February 2011 calling on executive branch agencies to immediately use the HSPD-12 cards for all new online systems under development and, beginning in fiscal 2012, to upgrade existing systems to handle them.

Then in October 2011, U.S. CIO Steven VanRoekel issued a memo requiring agencies to begin enabling government websites operating at the lowest level of identity assurance, or Level 1, to accept externally issued credentials in accordance with governmentwide requirements. All federal sites must be compliant at that level within three years.

“The fact that VanRoekel had to issue that memo tells you how much success there has been to date,” said Ian Glazer, a research vice president who leads the identity and privacy strategies team at Gartner.

Hannah said agencies should not have too much difficulty making the technical modifications to websites to accept Level 1 credentials. The much tougher work comes when they want to accept credentials for levels 2, 3 and 4, where NSTIC is intended to make its biggest impact.

“Whoever is receiving that [higher-level] credential in a federated manner must trust the fact that that identity was proofed, was vetted, and the account was set up in a way that can be completely trusted to that level,” Hannah said. “You can never say that the technical stuff is easy, but relatively speaking, I think it’s going to be the easiest part.”

Understanding assurance levels

The National Institute of Standards and Technology has defined technical requirements for various levels of authenticating individuals’ identities online. The General Services Administration uses those standards when it certifies identity management systems for government use.

Experts say federal agencies are making the most progress in developing applications that support transactions at the lowest assurance level because the cost and complexity bar is low and at the highest level because certain highly sensitive government applications can justify the greater expense.

The National Strategy for Trusted Identities in Cyberspace aims to kick-start and facilitate development in levels 2 and 3, where implementation challenges are big and the return-on-investment calculations are more complicated. Here is a look at the various levels’ requirements.

Assurance Level 1

  • Confidence: Little or none; identity usually self-asserted.
  • Example: Self-registration websites, such as news and social media sites.
  • Identity proofing requirements: None.
  • Token (secrecy) requirements: Any type of token, including a personal identification number.

Assurance Level 2

  • Confidence: Some confidence that the asserted identity is accurate.
  • Example: Changing the address in an account beneficiary’s record.
  • Identity proofing requirements: Requires some identity proofing.
  • Token (secrecy) requirements: Single-factor remote authentication, typically a password.

Assurance Level 3

  • Confidence: High.
  • Example: Access to an online benefits or brokerage account.
  • Identity proofing requirements: Stringent.
  • Token (secrecy) requirements: Multifactor authentication, typically a password or biometric factor used in combination with user possession of a software token (stored in a Web browser, for example), a hardware token (such as a smart card or key fob) or a one-time password device token.

Assurance Level 4

  • Confidence: Very high.
  • Example: Access to government buildings and networks via agency-issued smart cards, such as Common Access Cards.
  • Identity proofing requirements: In-person registration.
  • Token (secrecy) requirements: Multifactor authentication that must include a hardware token with cryptography.

Sources: National Institute of Standards and Technology, Office of Management and Budget, Federal Computer Week