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

X
This website uses cookies to enhance user experience and to analyze performance and traffic on our website. We also share information about your use of our site with our social media, advertising and analytics partners. Learn More / Do Not Sell My Personal Information
Accept Cookies
X
Cookie Preferences Cookie List

Do Not Sell My Personal Information

When you visit our website, we store cookies on your browser to collect information. The information collected might relate to you, your preferences or your device, and is mostly used to make the site work as you expect it to and to provide a more personalized web experience. However, you can choose not to allow certain types of cookies, which may impact your experience of the site and the services we are able to offer. Click on the different category headings to find out more and change our default settings according to your preference. You cannot opt-out of our First Party Strictly Necessary Cookies as they are deployed in order to ensure the proper functioning of our website (such as prompting the cookie banner and remembering your settings, to log into your account, to redirect you when you log out, etc.). For more information about the First and Third Party Cookies used please follow this link.

Allow All Cookies

Manage Consent Preferences

Strictly Necessary Cookies - Always Active

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Sale of Personal Data, Targeting & Social Media Cookies

Under the California Consumer Privacy Act, you have the right to opt-out of the sale of your personal information to third parties. These cookies collect information for analytics and to personalize your experience with targeted ads. You may exercise your right to opt out of the sale of personal information by using this toggle switch. If you opt out we will not be able to offer you personalised ads and will not hand over your personal information to any third parties. Additionally, you may contact our legal department for further clarification about your rights as a California consumer by using this Exercise My Rights link

If you have enabled privacy controls on your browser (such as a plugin), we have to take that as a valid request to opt-out. Therefore we would not be able to track your activity through the web. This may affect our ability to personalize ads according to your preferences.

Targeting cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Social media cookies are set by a range of social media services that we have added to the site to enable you to share our content with your friends and networks. They are capable of tracking your browser across other sites and building up a profile of your interests. This may impact the content and messages you see on other websites you visit. If you do not allow these cookies you may not be able to use or see these sharing tools.

If you want to opt out of all of our lead reports and lists, please submit a privacy request at our Do Not Sell page.

Save Settings
Cookie Preferences Cookie List

Cookie List

A cookie is a small piece of data (text file) that a website – when visited by a user – asks your browser to store on your device in order to remember information about you, such as your language preference or login information. Those cookies are set by us and called first-party cookies. We also use third-party cookies – which are cookies from a domain different than the domain of the website you are visiting – for our advertising and marketing efforts. More specifically, we use cookies and other tracking technologies for the following purposes:

Strictly Necessary Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Functional Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Performance Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Sale of Personal Data

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.

Social Media Cookies

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.

Targeting Cookies

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.