The notion of an identity ecosystem seems like a good idea. Provide a single credential that individuals can use for secure or anonymous access to Internet sites without having to remember dozens of user names and passwords.

And while it may seem like a simple idea, the implementation of such an identity ecosystem is anything but simple. An identity ecosystem, such as that proposed in the National Strategy for Trusted Identities in Cyberspace, is complicated because one hasn’t existed to the extent that the strategy proposes.

Google, Facebook Connect, InCommon, OpenID, the U.S. federal government’s PIV are all identity ecosystems but none fulfill the vision of the national strategy that combines both low and high-assurance identities. Bringing together identity providers, attribute providers, consumers and relying parties for the purpose of issuing, using and accepting a credential is no simple task. Pieces of the puzzle exist but taking what’s out there and making it work in the broader ecosystem is a monumental undertaking.

There are many pieces to consider. In the year since the national strategy document was released, progress has been made and the government is working to move the initiative forward. Organizations like the Kantara Initiative have developed identity assurance frameworks and policies to vet organizations so that they can issue high-assurance credentials.

From there spawn the companies that issue identity credentials to individuals. Telecommunications companies, financial institutions and credit reporting agencies are among those expressing interest in this arena.

There are also attribute providers. These are organizations that enable the credential to be used for different purposes. For example, a credential issued by a financial institution could receive an attribute from a telecommunications company or a social network to perform different tasks. Exactly how these will work and play with the credentials providers is the subject of discussion.

Finally, there are relying parties who will accept the credentials issued in the identity ecosystem. Outside of the consumer who will use the credential, the relying party is arguably the most important part of the ecosystem. Thus far, however, they have been virtually silent when it comes to the national strategy, an issue government officials are aware of and are trying to remedy.

Moving the ball forward

Jeremy Grant is not new to the identity and credentialing market. As a U.S. Senate aide he helped draft legislation that set the foundation for the U.S. Defense Department’s Common Access Card and the General Service Administration’s smart card efforts.

Grant then went to Maximus, one of the three GSA certified smart card providers at the time, where he led the company’s Security and Identity Management practice working on a number of U.S. smart card projects. He then spent three years with Washington Research Group as the firm’s identity and cybersecurity market analyst.

He joined NIST last year to lead the government’s team on the national strategy. “One of the most exciting things we’ve seen over the last year is the large number of stakeholders,” Grant says. “From Fortune 500 companies to niche security firms building predicates to relying parties … they are all participating and think the strategy makes sense. This suggests that the president has been able to move the marketplace forward.”

Grant wants to reiterate that it’s not the government making technical decisions. “The implementation needs to be led by the private sector,” he says. “The government should be a facilitator so the evolution of the ecosystem can be realized more quickly.”

Funding pilots for the national strategy and establishing the steering committee are two ways the government is helping to move the identity ecosystem along, Grant says.

The 27 finalists for pilot grants were notified in April and their proposals were due in early May with awards expected in July. The formation of the steering committee will also move the identity ecosystem forward. One of the first tasks for that group will be coming up with an accreditation program and a trust framework.

What is a trust framework?

At its most basic level a trust framework is a set of rules that enable a credential to be trusted by someone who did not issue it. For example, if a financial institution issues a credential to an individual a trust framework would have to be put in place so it could be used on a social networking or telecommunication Web site.

The Kantara Initiative works on helping create these trust frameworks, says Joni Brennan, executive director at the organization. For example, last fall Kantara was approved by the U.S. Government Services Administration as a Trust Framework Provider program certifying levels of assurance one, two, and three non-crypto–non-PKI.

The Kantara Identity Assurance Accreditation and Certification Program aims for the use of a trust framework model to build a public-private partnership that assures trust in the identity-based experience to end users, relying parties and federation operators. Kantara’s assessors perform testing of credential service providers–also known as identity providers–based on the Kantara Initiative’s Identity Assurance Framework.

The Kantara Identity Assurance Accreditation and Certification Program assesses applicants against its criteria ensuring alignment with the NIST 800-63 Levels of Assurance and grants successful candidates of the program the right to use the Kantara Initiative Mark, a symbol of trustworthy identity and credential management services at specified assurance levels.

For the past two years Kantara has been working on the foundation for these trust frameworks, Brennan says. Three companies–Deloitte, Electrosoft and eValid8–are accredited assessors while Verizon has certified to issue credentials up to level three assurance.

There are other credential providers working on certification as well, Brennan says.

The identity provider may be the most widely known component in the identity ecosystem. Many already exist depending on the desired level of assurance from the federal government’s PIV to self-asserted identities in Facebook.

Eventually, an individual will go to an identity provider for identity vetting and to receive the credential. From there the individual will be able to take that credential and use it for access to different sites.

But then there are also the attributes. While the credentials may be loaded with identity information and some basic attributes, it also needs other data to enable access to specific sites and functions.

What is an attribute?

At a very high level, think of a credential as a pass that gets an individual in the front door of an office building. But in order to access the elevator, different floors and offices within the building, attributes on the credentials have to be enabled.

There are attributes that are core to an identity and don’t change, others that change infrequently and still others that may change often. “Core identity attributes–such as name, date of birth and biometric information–don’t change,” says Salvatore D’Agostino, principal at IDmachines.

Down a level from that is information that doesn’t change very often, such as physical address, email address, banking information and medical records, D’Agostino says.

Another level down are attributes that may change more frequently. For example, a physician could have certification updated on the credential or an employer could add information that enables a personal credential to be used for work purposes.

Lastly are the attributes that could change often, such as those used to access social networking and ecommerce sites. This is an area where attributes become tricky. Sites will offer the attribute service for a low cost–or no cost–but then turn around and sell it to others. This is what Facebook and other social networking sites do now and will continue to do, D’Agostino says.

The problem with this last category of attributes is that in many cases they are already out there in the world, D’Agostino says. “Nobody did this intentionally but since no one has been keeping their eyes on the hen house the fox has been feasting,” he says. “At some point there will be push back that results in the fact that a lot of people’s information has been irrevocably leaked.”

For example, Facebook users who authorize an application or use the Connect feature have given that organization their personal information. Most people don’t realize the extent of the personal information they’re giving up when they hit that button, D’Agostino explains.

This highlights the need to manage attribute providers, which is what the national strategy wants to enable. As it stands now individuals don’t always control their attributes. “They’re given away, gathered or leaked,” D’Agostino says.

Before the Internet era the only information readily available about an individual was a listing in the white pages, name address and telephone number. These days it would be rare if that information weren’t available along with much more. “What books have I read? What plane am I on? People put this information out there,” D’Agostino says. “In the meantime some companies have taken advantage that there isn’t control out there and are making money off it.”

Relying parties

Many say the biggest missing piece of the identity ecosystem puzzle is the relying parties. There are people champing at the bit to issue credentials but who’s going to accept them?

NIST is going to focus more on bringing relying parties into the national strategy conversation, says Grant. “Many have come to use but it’s probably the group that’s most under represented in our discussions,” he admits. “We’re doing more proactive outreach to bring those parties to the table.”

A lingering question surrounds why corporations should accept credentials that come out of a national strategy, says Gary Moore, chief architect for Government Solutions at logical access solutions provider Venafi. The quick answer is that organizations will save money by not having to run their own identity management system. But these attributes will have to be handled securely, without leakage, and consumers will have to be educated.

“Part of this is because of Facebook,” Moore says. “When you link services they tell you what the other site can see but people don’t know what that means. Some don’t want to do that so they just create a separate user name and password.”

The federal government has vowed to be one of the first relying parties to accept these credentials. While this is a good first step, the focus should be on bringing in others, Moore says. “From an altruistic perspective it’s a great initiative but the issue we’re facing is that not everyone deals with the government enough to need that type of credential,” he explains. “To get this really used we need the companies consumers deal with on a regular basis … the banks and utility companies that people are touching regularly.”

Progress has to be made to convince these organizations that relying on another identity management system has merit, Moore says. “If these organizations can see the business value of reducing their identity management footprint they will see a benefit,” he says.

Don Thibeau, chairman and director at large at the Open Identity Exchange, says the relying parties are waiting for decisions to be made on governance and trust frameworks before entering the fray. But, he says it would be in their best interest to put some effort into identity management. “Ecommerce merchants are making it up as they go along and that doesn’t work for anyone,” Thibeau says.

There needs to be a value proposition for retailers, beyond simply not having to maintain their own ID management system, Thibeau says. “When someone goes to Best Buy, be it brick and mortar or Web site, wouldn’t be useful to know the individual walking in the door?” he asks. “If you knew who they were you could make them a special offer and give them a better shopping experience.”

There also needs to be a governance structure before relying parties will participate, says Keith Ward, president and CEO at the Transglobal Secure Collaboration Program. Until corporations know what rules they need to abide by they will remain on the sidelines. “Relying parties don’t care about technology, they are focused on the legal and privacy issues,” he stresses.

How to enable trust?

Thibeau, who is representing Google and others when it comes to discussion of the national strategy, says that identity ecosystems already exist in products like OpenID and Google. “Someone asked Eric Schmidt [Google executive chairman] to describe the difference between Google+ and Facebook,” Thibeau explains. “He said ‘trust.'”

This goes to Google+ requiring real names. If an individual signed up with what seems like a pseudonym or fake name their account is suspended. They are then contacted and asked to prove their name by providing a copy of a government ID. Schmidt has made multiple overtures in the media about Google’s ambition to become an online identity provider.

Requiring real names is one step, but organizations need a way to vet that name to an individual. That requires trust, the magic word when it comes to the identity ecosystem. “The more you trust something the more you can do with it,” Thibeau says. “Trust has powerful economic definitions, the more you trust a particular brand, the more you transact with it.”

How to elevate that trust is a topic of major discussion. The American Bar Association Identity Management Task Force has an email list where this is hotly debated. One group favors using a PIV-I type of standard while others favor a solution more akin to Facebook Connect or OpenID. “It’s the very well developed PKI world versus the wild, wild west of social media,” Thibeau says. ” I don’t think we can see that middle ground yet but it’s there.”

The middle ground may appear in the form of derived credentials, says Jeff Nigriny, CEO at Certipath. This type of system would have one credential that could spawn others as necessary depending on the level of assurance required for a transaction.

For example, a wire transfer exceeding a certain dollar figure would require a high assurance credential and request additional authentication information before the transaction is complete. But if an individual simply wanted access a Web site without creating another login, that original credential could serve as a low-assurance identification token for the site.

But it’s easier said than done. “If the entity already has a high-assurance credential, it is easy to understand that should be inherently trusted by an application that wants mid-level assurance,” Nigriny says. “However credential technologies and the software that consumes them are not that flexible. A service that provides a derivative credential in the form factor suitable for the application is likely a winning technology migration strategy.”

Conversely, if an individual has a low-assurance credential a higher-level site may want to use it as an index to establish an ID and then prompt that user to step up the identity via a stronger credential. For example, a financial services company could accept a social networking ID to begin the ID process, but then request additional information to complete login and enable transactions.

It’s yet to be seen how this will play out in practice and how the business case will develop. Thibeau says the Open Identity Exchange can work with vendors to bring a higher level of assurance to email addresses with PKI. The organization also sees itself having a role in defining, implementing and enforcing this trust framework, Thibeau says. “You need a referee and someone enforcing the trust framework,” he adds.

Thibeau says that the Open Identity Exchange is in a perfect position as its membership is really a team of rivals each having a function in the identity ecosystem. Telecommunications, data aggregators and payment companies all are members of Open Identity Exchange and all have a place in the ecosystem. “The common denominator among all these rivals is that they need to figure out how to work with government,” he says.

Whether working with the government or the myriad of other of players who make up the puzzle that is the identity ecosystem, progress is occurring. As pilots roll out later this year, trust frameworks and governance models are adopted and the steering committee is put in place, a year from now the identity ecosystem puzzle should have far fewer missing pieces.

---

Identity ecosystem: InCommon

When the National Strategy for Trusted Identities in Cyberspace was first unveiled it reminded Ken Klingenstein of a document InCommon had created more than a decade prior. “The ID service provider, attribute authority and inter-federation were all elements of our world in 2001,” he says.

InCommon, with 275 higher education participants and 105 sponsored partners, was created to support a common trust framework for education and research institutions in the U.S. This includes trusted shared management of access to online resources.

To achieve this, InCommon helped develop a community-based common trust framework to enable participants to make appropriate decisions about the release of identity information and access control to protected resources. InCommon is intended to enable end-user access to a wide variety of protected resources.

Through InCommon, identity providers can give users single sign-on and privacy protection, while online service providers control access to their protected resources. Since InCommon already has established operating principles, technology hooks and agreed-upon data exchange elements with each partner a new organization doesn’t have to spend the time or resources to create these.

Here’s how it works: a user clicks on a service provider’s resource. Using federated single sign-on software, an identity provider authenticates a user releasing only enough identity data to enable the service provider to make an access decision.

InCommon, and many of the institutions it works with, use Shibboleth, a federated identity solution that connects users to applications both within and between organizations. Every software component of the Shibboleth system is free and open source. It provides single sign-on capabilities and enables sites to make informed authorization decisions for individual access to protected online resources in a privacy-preserving manner.

InCommon has many case studies and deployments at colleges and universities. One involved Stanford University and the National Student Clearinghouse. The solution enabled Stanford students to use their university access credentials for access to transcripts at the clearinghouse.

Lafayette College, Easton, Pa., used InCommon so students could purchase tickets to different events. Lafayette wanted to provide student-only tickets to campus events through an agreement with UniversityTickets. The Dean of Students office worked with the company, but ran up against the challenge of providing user IDs and passwords for all 2,300-plus students.

Lafayette had already been using InCommon for library applications and the Moodle course management system. The school introduced UniversityTickets to InCommon, the company joined and installed the Shibboleth service provider software. Students can now use their university issued credentials to purchase tickets to campus events.

In its more than 10-years of existence, InCommon has grown significantly and with the national strategy it sees further growth with the creation of multi-lateral federations, Klingenstein says. “InCommon will grow significantly and evolve into a distinct sub community,” he adds. “Others will evolve into different federations as things become more polished.”

The attributes are going to be what causes these different federations to pop up and then connect, Klingenstein says. For example, the attributes that InCommon use won’t work for a K-12 school so separate ones are needed. Additionally, medical organizations have been joining InCommon in preparation for inter-federation with research institutions. This too will necessitate another attribute set.

While the majority of efforts for InCommon have focused on federation and single sign-on, these new efforts will add two-factor authentication as well, Klingenstein says.

---

TSCP wants to pilot trust framework

In April the National Institute of Standards and Technology notified the organizations that made the cut for National Strategy for Trusted Identities in Cyberspace grants.

Rules prohibited NIST from announcing the finalists publically but the groups were free to publicize. The only one of the 27 to come forward was the Transglobal Secure Collaboration Program (TSCP).

TSCP’s proposal addresses the trust framework, governance, liability and privacy of the national strategy and an identity ecosystem, says Keith Ward, president and CEO at the organization. The proposal wants to look at using high-assurance credentials for purposes other than their original use. “Hundreds of millions of dollars have been invested to deploy high-level assurance credentials,” he says. “But when you look at PIV and PIV-I they’re still single use cards.”

TSCP wants to look at the liability and governance structures that would be necessary to use these credentials for other purposes. “How do you take those credentials and put them into the mainstream?” Ward asks.

For example, a defense contractor uses his PIV-I for access to networks on the job and to authorize procurements for projects. But when that same defense contactor calls it a day at the office he goes home where he’s a volunteer firefighter and first responder. How can his work credential serve him in his other roles? Can this use be extended to enable secure login to a government Web sites, to reserve a camping site at a federal park or to save information on a federal Web portal?

“This last level is where it breaks down,” Ward says. “There’s no way to use that high-level card, without opening up liability and privacy issues.” In other words, taking a high-assurance certificate and opening it up for lower level transactions could jeopardize its integrity.

While PIV and PIV-I are used as an example the issue extends to any credential. “We’re trying to address the broader range of the ecosystem,” Ward says.

---

What is federated identity?

A federation is a collection of organizations that have agreed to interoperate using a common set of rules, particularly in the areas of privacy and security. Because of these agreements, federation members do not have to negotiate individually with every other member. Federations also agree on standard methods for authentication and authorization.

Federations include identity providers and service providers. Identity providers maintain identity databases and authenticate users. Service providers have a protected online resource and authorize users. With sound federation trust agreements, an identity provider need only release the information the service provider requires to make an authorization decision.

The service provider does not need to maintain user databases. Instead it leverages the identity providers identity system.

Federations will usually define a trust fabric, provide a set of agreed-on attributes used for exchanging information, offer software to enable authentication and authorization and distribute the metadata necessary for interoperability.

Source: InCommon

---

Defining the identity ecosystem

Trust Framework:
A trust framework is an agreement between organizations to accept a credential issued by another. They enable a credential issued by one provider to be used at another provider. Trust frameworks put rules and policies in place to make sure that everyone is following the same map for issuance and use of a credential.

Identity provider:
The organizations that perform the identity proofing and issuance of a credential are called identity providers. There are a handful of companies performing this task now–from financial institutions to telecommunications firms–with more expected to jump into the fray in the near future. Whether this identity proofing and issuance is done in person or online will depend on the credential’s level of assurance.

Attribute Provider:
An attribute is a piece of information about an individual, such as name, email and telephone number. An attribute provider may be an identity provider or it could be another organization that simply adds attributes to an existing credential. For example, an employee could have a credential used for personal use and the company they work for could add attributes so it can be used for a work credential as well.

Relying Party:
This is the organization that will consume the identity credentials. Relying parties include banks, utility companies and merchants who will accept the credentials for online access and authorization.