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)

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.