higgins, the trust framework
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare the intent and scope of a proposed Technology PMC Project called Higgins, the Trust Framework Project, or Higgins. (Note that its original name was the Eclipse Trust Framework or ETF, so some of the material will still have the old name.) In addition, this proposal is written to solicit additional participation and inputs from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.etf newsgroup.
Background
The need to improve interoperability, security and privacy in loosely coupled architectures, especially those that span organizational boundaries has in recent years increased the prominence of identity management systems. These systems maintain a real or virtual directory of identities, each with profile attributes, roles, access permissions and so on. There is often a need to manage more than just “point” identities (i.e. the digital identifiers and profiles of people and systems). Many applications need to manage relationships between identities—what we call the social context. Examples of these applications include groupware, virtual directories, social networking and patient centered healthcare.
We use the term context to cover a range of underlying implementations from directory systems like LDAP to social networking systems like FOAFnet or Friendster. A context can be thought of as a distributed container-like object that contains the digital identities of multiple people or processes. A context can represent a team, a department, an association, a mailing list, a website, a customer group, a personal buddy list, or a list of web services.
The Higgins Trust Framework platform 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.
Description (scope and goals)
Our goals are to:
1. Create a framework/API – an abstraction layer for identity and social networking services
2. Create a set of exemplary context “provider” implementations (plug-ins)
3. Create an exemplary app that demonstrates how to use the extensible framework
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:
1. Initialization of the framework platform
2. The context interface (implemented by extensions to the context provider extension point)
3. 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:
1. Authentication of credentials for access
2. Authentication of each facet within the context
3. Authorization of access to facet profile data using role-based access control lists
4. Facet search and editing functions
5. Support for adding tag properties to facets and on the links between facets
6. Replication/distribution of context data to Higgins clients
7. Synchronization of context data
8. 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:
1. A simple Buddy List plug-in. We will create an EMF-based Context data model and use EMF, SDO and Eclipse ECF for replication and synchronization
2. A plug-in to an existing enterprise directory server
3. A plug-in for the Identity Commons (OASIS XRI-based) identity system
4. A plug-in for a WS-Trust/etc. based identity system
5. A plug-in for the FOAFnet networking system
6. 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:
1. A UI for viewing, editing and linking identities in multiple contexts
2. A UI for rating/reputation
3. Network visualization: ability to overlay the networks of multiple contexts to determine common relationships and characteristics
4. 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 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.
Organization
We propose this project should be undertaken as a Technology project rather than as part of the Eclipse Platform. Being a Technology project gives it room to experiment without disruption to other Eclipse Platform development work.
The life cycle of this project may be similar to the Equinox project. That is, once this work matures, it may be incorporated into the Eclipse Platform to provide a common open source substrate that industrial/commercial users could use to build solutions. Alternatively, it may continue as a technology subproject.
Suggested Project Lead and Committers
This section captures the list of organizations that have expressed interest
in the project and/or its components, and as such will be updated periodically
to reflect the growing interest in this project.
Rather than canvas the Eclipse community at large, the submitters of this proposal
welcome interested parties to post to the eclipse.technology.etf newsgroup
and ask to be added to the list as interested parties or to suggest changes
to this document.
Paul Trevithick
(Project Lead)
SocialPhysics.org; paul at SocialPhysics.org
Dmitry Bakuntsev
International Technology Group (ITG)
John Beatty
Andy Dale
ooTao
Ken Gilmer
Scott Lewis
Composent, Inc.
Peter Nehrer
S1 Corporation
Mary Ruddy
SocialPhysics.org; mary at SocialPhysics.org
Paul Weitz
Interested Parties SocialPhysics.org http://www.socialphysics.org IBM http://www.ibm.com/ Inpriva http://www.inpriva.com/ ITG http://www.intertechnogroup.com/ ooTao http://www.ootao.com/ Berkman Center for Internet & Society at Harvard Law http://cyber.law.harvard.edu/home/