Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Introduction to Higgins"

m
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 +
==Version==
 +
This is an obsolete page from the 2004-2005 era. Nothing should link to this page.
 +
 +
==Introduction==
 
Higgins is a framework that will enable users and enterprises to integrate identity, profile, and relationship information across multiple systems. Using ''context providers'', existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems. A design goal is that Higgins be useful in the development of applications accessed through browsers, rich clients, and web services. Our intent is to define the Higgins framework in terms of service descriptions, messages and port types consistent with an SOA model and to develop a Java binding and implementation as an initial reference.
 
Higgins is a framework that will enable users and enterprises to integrate identity, profile, and relationship information across multiple systems. Using ''context providers'', existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems. A design goal is that Higgins be useful in the development of applications accessed through browsers, rich clients, and web services. Our intent is to define the Higgins framework in terms of service descriptions, messages and port types consistent with an SOA model and to develop a Java binding and implementation as an initial reference.
  
Line 4: Line 9:
  
 
===Contexts===
 
===Contexts===
The Higgins service relies on a set of "plug-in" [[Context Provider]]s that either adapt existing legacy systems to the framework, or implement new ones. A context is "the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions." A context provider implements (or adapts) an existing context.  
+
The Higgins service relies on a set of "plug-in" Context Providers that either adapt existing legacy systems to the framework, or implement new ones. A context is "the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions." A context provider implements (or adapts) an existing context.  
  
''Note: In the initial Java reference implementation, these [[Context Provider]]s are expressed as Eclipse extensions that implement Java interfaces (e.g. IContext, IDigitalSubject, etc.). These extensions are usually packaged as separate Eclipse plug-ins (or more correctly, OSGI'' bundles'').''  
+
''Note: In the initial Java reference implementation, these Context Providers are expressed as Eclipse extensions that implement Java interfaces (e.g. IContext, etc.). These extensions are usually packaged as separate Eclipse plug-ins (or more correctly, OSGI'' bundles'').''  
  
A [[Context]] may contain information about a single [[Digital Subject]], or it may represent a group of [[Digital Subject]]s such as a project team, department, association, informal network, family, customer group, and so on. A context contains a set of one or more [[Digital Subject]]s each with its associated [[Identity Attribute]]s, may contain relationship links, to other [[Digital Subject]]s, and may contain metadata attribute about the nature of these relationships.
+
A Context may contain information about a single Entity or it may represent a group of Entities such as a project team, department, association, informal network, family, customer group, and so on. A context contains a set of one or more Entities each with its associated Attributes, may contain relationship links, to other Entities, and may contain metadata attribute about the nature of these relationships.
  
 
'''Multiple Contexts'''
 
'''Multiple Contexts'''
Line 17: Line 22:
 
Context providers most often act as "adapters" to existing systems. Adapter providers can connect to ''directories'' such as LDAP servers, identity management systems, mailing lists, and social networking systems. They may also adapt ''collaboration spaces'' such as file repositories and other shared spaces. Or they may adapt ''communications'' networks such as email, IM or voice.  
 
Context providers most often act as "adapters" to existing systems. Adapter providers can connect to ''directories'' such as LDAP servers, identity management systems, mailing lists, and social networking systems. They may also adapt ''collaboration spaces'' such as file repositories and other shared spaces. Or they may adapt ''communications'' networks such as email, IM or voice.  
  
A [[Context]] maintains a set of [[Digital Subject]]s. A [[Digital Subject]] is a set of [[Identity Attribute]]s with associated values (e.g. name, address, etc.). The schema for these attributes varies by [[Context]].
+
A Context maintains a set of Entities. An Entity is a set of Attributes with associated values (e.g. name, address, etc.). The schema for these attributes varies by Context.
  
 
[[Image:Higgins_v6.jpg]]
 
[[Image:Higgins_v6.jpg]]
Line 23: Line 28:
 
===Higgins-based applications===
 
===Higgins-based applications===
 
Applications use the Higgins to insulate themselves from the details and complexities of each distinct collaboration space, communications system, or enterprise directory. Higgins's service architecture allows applications to use and access an ever increasing range of external systems without any changes to the application itself.
 
Applications use the Higgins to insulate themselves from the details and complexities of each distinct collaboration space, communications system, or enterprise directory. Higgins's service architecture allows applications to use and access an ever increasing range of external systems without any changes to the application itself.
 
 
===Motivation for Higgins===
 
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.  More and more it is realized that top-down, enteriprise oriented, approaches have limitations, and there are many use cases where it makes sense to organize identity information from the point of view of the user. Also, 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, and social networking.
 
 
Higgins intends to address four challenges: the need to manage multiple contexts, the need for interoperability,  the need to respond to regulatory, public or customer pressure to implement solutions based on trusted infrastructure that offers security and privacy, and the lack of common interfaces to identity/networking systems.
 
 
'''The need to manage multiple contexts.''' The existence of common identity/networking framework also makes possible new kinds of applications. Applications that make it easy to manage identities, relationships, reputation and trust within and 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 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 for trusted infrastructure.''' The lack of a trusted infrastructure that allows people to selectively share information on the web while protecting their privacy is limiting the growth and use of the Internet.  Working in partnership with development organizations 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.  These new capabilities will enable a next generation web sometimes called the Augmented Social Network (ASN) or Social Web.
 
 
'''Lack of common interfaces.'''  The application developer who needs to integrate an identity/networking system is forced to learn the intricies 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 services, and encourage developers to create "provider" services for existing and new identity/networking systems.
 

Latest revision as of 13:14, 20 August 2014

Higgins logo 76Wx100H.jpg

Version

This is an obsolete page from the 2004-2005 era. Nothing should link to this page.

Introduction

Higgins is a framework that will enable users and enterprises to integrate identity, profile, and relationship information across multiple systems. Using context providers, existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems. A design goal is that Higgins be useful in the development of applications accessed through browsers, rich clients, and web services. Our intent is to define the Higgins framework in terms of service descriptions, messages and port types consistent with an SOA model and to develop a Java binding and implementation as an initial reference.

Applications can use Higgins to create a unified, virtual view of identity, profile and relationship information. A key focus of Higgins is providing a foundation for new "user-centric identity" and personal information management applications. Higgins provides virtual integration, user-centric federation, management, trust brokering, linking, and search capabilities that are applied to identity, profile and relationship information across multiple contexts and across disparate systems and implementations.

Contexts

The Higgins service relies on a set of "plug-in" Context Providers that either adapt existing legacy systems to the framework, or implement new ones. A context is "the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions." A context provider implements (or adapts) an existing context.

Note: In the initial Java reference implementation, these Context Providers are expressed as Eclipse extensions that implement Java interfaces (e.g. IContext, etc.). These extensions are usually packaged as separate Eclipse plug-ins (or more correctly, OSGI bundles).

A Context may contain information about a single Entity or it may represent a group of Entities such as a project team, department, association, informal network, family, customer group, and so on. A context contains a set of one or more Entities each with its associated Attributes, may contain relationship links, to other Entities, and may contain metadata attribute about the nature of these relationships.

Multiple Contexts

Higgins arch v11.jpg


Context providers most often act as "adapters" to existing systems. Adapter providers can connect to directories such as LDAP servers, identity management systems, mailing lists, and social networking systems. They may also adapt collaboration spaces such as file repositories and other shared spaces. Or they may adapt communications networks such as email, IM or voice.

A Context maintains a set of Entities. An Entity is a set of Attributes with associated values (e.g. name, address, etc.). The schema for these attributes varies by Context.

Higgins v6.jpg

Higgins-based applications

Applications use the Higgins to insulate themselves from the details and complexities of each distinct collaboration space, communications system, or enterprise directory. Higgins's service architecture allows applications to use and access an ever increasing range of external systems without any changes to the application itself.

Back to the top