SourceID is an open source project that will incorporate ideas, protocols, and software to support open identity as well as the creation of an open-source identity management system. Several of the projects under this initiative include development of a federated identity exchange to enable seamless single sign-on that will be 100% interoperable with the Liberty Alliance project. Development of an identity server, to provide identity in an open peer-to-peer manner for use by enterprises and service providers, is also underway. The SourceID project is the sole identity solution that puts control of identity into the hands of the identity owner. Other initiatives, such as Passport and the Liberty Alliance, are driven by corporations and software vendors. SourceID will allow users to host identity on their own computers if they desire.

Additional information on SourceID is available at .

SourceID's goal is important because developers currently do not have any tools or libraries to develop solutions to interact with single sign-on protocols, such as Liberty Alliance. SourceID provides value to developers at large corporations who do not have time to learn SAML, Liberty, or other APIs that will be developed as part of the Java Community Process. SourceID tools provide well-documented plug-in points that allow developers to insert bridge code into the SourceID SSO kernel. These plug points support identity storage, retrieval, authentication, and authorization. The first release of the API is targeted toward developers who write Java servlets and JavaServer Pages. Future releases of SourceID will also support Microsoft's ASP.NET. To understand SourceID a little better requires understanding the strengths and limitations of competing and complementary technologies, such as SAML and The Liberty Alliance. Let's compare SourceID to SAML first. SAML is a complete specification but also offers more than SSO requires. It does provide benefits, such as specifying a timestamp and network location of the identity host, which help prevent forgery, but it is also verbose in its layers. SourceID will use SAML for authentication but will defer to other protocols for identity management. The Liberty Alliance specification addresses federated authentication among identity and service providers and works based on circles of trust. Liberty Alliance was originally started by Oracle under the guise of open standards. The Liberty Alliance specifications specify how to join identities from various sources, such as the companies that make up the alliance. Each pair of companies that participates has many user accounts between them, but no relationship information is available. Liberty Alliance allows these identities to be joined, making it convenient when consumers visit their sites. By joining identity across sites, the organizations that adopt this standard can reduce the cost of business, which can result in reduced cost to consumers. SourceID has a different focus. It provides the ability to host identities from a centralized location, which could be the user's personal computer, rather than spreading this information across multiple identity providers. Given the choice, consumers would rather have identity stored 100% in their control but would defer where appropriate to federated identity providers. An open identity-management solution must provide the following features:

Metadirectories provide the ability to abstract differences between disparate storage mediums that hold identity information, such as relational databases, LDAP, NIS, Active Directory, and others. This layer provides the capability to have a unified management and access facility for single sign-on apps. Provisioning of identity, especially in a self-service manner, will be vital for use on the Internet, where consumers may not be known to the businesses with which they intend to conduct commerce. The ability to support provisioning and self-service allows an organization to enjoy significant cost savings. For example, employees of Flute Bank can self-provision an identity for using services offered. Consumers of Flute Bank can also self-provision an identity, which can be submitted for approval before access is granted. Incorporation of workflow is important, especially if it requires governmental licensing, security clearances, or other nontrivial validation procedures. Delegated administration is an important feature that can help reduce calls to a central help desk. For example, a husband can have delegated authority to reset his wife's password. Software development kits are required for developers to programmatically access identity information and build functionality into their Web sites and backend infrastructure. Ideally, they will use an open standard, such as SOAP. Authentication, authorization, and the ability to protect resources should be supported so that they can be configured to work with Web servers, such as Apache and Microsoft's IIS. These proxies support the ability to intercept requests for resources (URLs) and validate that the end user is authorized to access the resource. Proxies should also support the ability to inspect SOAP messages and optionally be inserted into app servers, such as BEA's WebLogic and IBM's WebSphere, as a custom authentication realm. Many identity provider solutions will be available, from custom-built to products such as Netegrity's Siteminder to implementations that conform to the Liberty Alliance specification. Interoperability between SourceID supports these implementations and will seek to address scenarios not currently covered by the Liberty Alliance, such as peer-to-peer exchanges, auto forms population, and global lost and found. Peer-to-peer exchanges are inherently ad hoc and counter the notion of circles of trust. Yet in a peer-to-peer exchange, the notion of identity exchange occurs. One example is when using a wireless phone or Bluetooth-enabled device. You can keep a copy of your contacts in Microsoft Outlook on your Bluetooth-enabled Compaq iPaq . Whenever someone walks into range, the iPaq can notify you that his or her contact information is out of date and automatically update it, based on automatic credential exchanges that could be built into each wireless device. The constant task of updating data with each visit to a Web site or Web service can be frustrating. One would be to simply provide a SourceID network address that points to your identity. The Web site or service could automatically query and retrieve all basic information you have permitted, without user intervention. The site could do this on a periodic basis, to keep basic information up to date within its own systems. This could be further extended to automatically populate forms in Web sites or even fat clients. The notion of a global lost and found could be extended to wireless devices, which could have universally unique identifiers assigned to them. This would allow these devices to be accessed and managed through a Web service interface from anywhere in the world. The devices and their owners could also be registered with a service that monitors usage. If a registered device is lost or stolen, the owner could report it and render it useless by removing its identity. This could be extended to cars, televisions, airplanes, and other valuables.

Implementing identity management will be difficult for organizations. Tradeoffs exist in whether you want a single software company (e.g., Microsoft) to provide the solution (Passport), a consortium of large organizations who pay significant membership fees to participate in a consortium (Liberty Alliance). or identity presented via grassroots efforts (SourceID) without any form of vendor support. The discussion of this topic is highly religious and subject to debate even among the author team. What is important is that when constructing your architecture, you do homework on all the options presented. The best solution over time will always win.