The Higgins Trust Framework intends to address four challenges: the lack of common interfaces to identity/networking systems, the need for interoperability, the need to manage multiple contexts, and the need to respond to regulatory, public or customer pressure to implement solutions based on trusted infrastructure that offers security and privacy.

Lack of common interfaces. The application developer who needs to integrate an identity/networking system is forced to learn the intricacies of each different system. The lack of a common API means that this learning investment is not transferable. This project intends to develop a common API/framework, provide sample plug-ins, and encourage developers to create “provider” plug-ins for existing and new identity/networking systems.

The need for interoperability. Although there have been and will likely continue to be attempts to create a single universal identity system, the reality is that we’ll live in a heterogeneous world for a very long time. Rather than introduce yet another new identity system, instead Higgins introduces a new “context” abstraction and allows developers to create adapters to legacy systems. Systems operating above the abstraction layer have to potential to link identities across identity system boundaries.

The need to manage multiple contexts. The existence of common identity/networking framework also makes possible new kinds of applications. Applications that manage identities, relationships, reputation and trust across multiple contexts. Of particular interest are applications that work on behalf of a user to manage their own profiles, relationships, and reputation across their various personal and professional groups, teams, and other organizational affiliations while preserving their privacy. These applications could provide users with the ability to: discover new groups through shared affinities; find new team members based on reputation and background; sort, filter and visualize their social networks. Applications could be used by organizations to build and manage their networks of networks.

The need for trusted infrastructure. Working in partnership with our development partners and academic research groups, this project will create a key part of the open source infrastructure required for an open, accountable, socially-searchable web while ensuring privacy and personal control over identity information.

Because the Higgins trust framework is intended to interoperate with identity systems, the Higgins project can also provide a home to Eclipse-based reference implementations of identity systems /identity system interfaces.

The goals of the Higgins Trust Framework Project are to:

1. 1. Create a framework/API – an abstraction layer for identity and social networking services
2. 2. Create a set of exemplary context “provider” implementations (plug-ins)
3. 3. Create an exemplary app that demonstrates how to use the extensible framework
4. 4. Enable developers to leverage Higgins in their applications

(1) Framework/API

The extensible framework will support an API for use by Eclipse plug-ins and applications. The API could also be accessible via a web services interface. The API will provide:

• Initialization of the framework platform
• The context interface (implemented by extensions to the context provider extension point)
• Context management services (e.g. managing the registry of context provider plug-ins; resolving a context reference to a network location and a context provider implementation plug-in; loading and discarding of contexts, etc.)

The center of the extensible framework design is the plug-able context interface. A context is a container of facets. A facet a person or process that has been authenticated within its containing context. A facet has a profile which is comprised of a set of RDF properties and values (e.g. name, address, etc.). A facet also has one or more roles within the context. The set of profile properties and the set of roles and the access rights for each role are defined by and controlled by the context provider implementation.

Context provider implementations are responsible for:

• Authentication of credentials for access
• Authentication of each facet within the context
• Authorization of access to facet profile data using role-based access control lists
• Facet search and editing functions
• Support for adding tag properties to facets and on the links between facets
• Replication/distribution of context data to Higgins clients
• Synchronization of context data
• Persistence and encryption of context data
  •  Note1: Some context providers will provide only a subset of the features listed above.
  •  Note2: The communications protocols and topology (e.g. client/server or P2P) are implementation dependent.

 (2) Exemplary Context plug-ins

Our plan is to create the following exemplary set of context “provider” plug-ins:

• A simple ProfileShare plug-in. We will create an EMF-based Context data model and use EMF, SDO and Eclipse ECF for replication and synchronization
• A plug-in to an existing enterprise directory server
• A plug-in for the Identity Commons (OASIS XRI-based) identity system
• A plug-in for a WS-Trust/etc. based identity system
• A plug-in for the FOAFnet networking system
• A plug-in for Microsoft’s Outlook email client that creates a context containing a network of interlinked facets representing the user’s social network

 (3) Exemplary Application

The extensible Higgins Trust Framework makes possible new kinds of applications that manage the user’s identity across multiple contexts. We plan on creating an RCP demonstration application that can manage contexts from any of the above exemplary plug-ins that includes:

• A UI for viewing, editing and linking identities in multiple contexts
• A UI for rating/reputation
• Network visualization: ability to overlay the networks of multiple contexts to determine common relationships and characteristics
• Social network search functionality

 (4) Enable developers to leverage Higgins

Our hope is that developers can use Higgins to more easily implement identity and networking-related functionality in their applications, instead of creating this functionality from scratch. Here are some examples. They could use an existing Higgins context provider to manage the list of identities, member records, etc. as well as all associated attribute data used by their application. They could use the Higgins’ context abstraction as “glue” to integrate multiple existing enterprise directories.  They could add “peripheral vision” of other co-worker’s member’s online presence, contact information, and reputation to existing apps.