Beyond Higgins 1.0

A page for Higgins concepts that will be addressed beyond the initial release 1.0. In each release (e.g. Higgins 1.1) we'll pick a few of these futures and implement them.

Note: we're just getting started filling in this page. The upcoming Jan 8-10 Provo F2F Agenda will be the first place where we start the design work and discussions around these topics.

Ontology-related

The next two sections are deeply intertwined...

Ontology description language

• We currently use OWL 1.0
• Now that we've got some experience with OWL we see its limitations
• Should we move to OWL 1.1 or to something else?

Higgins Ontology: HOWL

• Today we have an extremely limited base, common ontology (higgins.owl AKA HOWL)
• HOWL, although syntactically valid, is incompatible with mainstream uses of OWL. The implication is that we can't directly re-use other existing ontologies

Recruitment

• The Higgins project has done very little outreach to attract other developers.
• Should we have a campaign to reach out more?

Liaisons

Need more liaison/dialog with:

• http://fstc.org
• ...lots more

I-Card Selector UIs

• Higgins is blessed(!) with multiple i-card selector UIs (DigitalMe Linux, DigitalMe OSx, Eclipse-based, web-based-Firefox(in-browser), web-based-IE)
• Need to reduce the number of parallel implementations
• Need to converge on a common UI
• Need to improve the UI

SAML IdP

• Higgins has a baby, prototype SAML 2.0 IdP
• Need to figure out how it properly integrates with the Token Service [see why I prefer not to call it an STS?--Paul]

Web-based Selector: HBX Authentication and the Selector Service

• Today the web-based selector uses a username (community i-name) and master password to authenticate directly to the selector service.
• Another approach is factor out authentication to a separate web service (to allow a choice of approaches). This service could provide a non-identifying token to provision and/or authenticate to an account on the selector service. (Such an approach also has the advantage of opening new models of authentication in the future.)
• Two simple protocols are being developed for this purpose:
  • HBXP is an HBX Provisioning protocol for registering the HBX with an IdP and a selector service.
  • HBX Auth is a authentication protocol for authenticating the user and the HBX to the IdP.

New Candidate Layers over the IdAS API

This section describes several sets of functionality that could be layered over the current IdAS API.

XDI Web service endpoint

As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint.

• Can only be implemented as a layer over IdAS, not as a Context Provider

Deep Search and Access

Although the Higgins data model supports Subject Relations as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats Subject Relations no differently from other attributes. Many use-cases (esp. cross-contextual use cases) would expect that these links would be recursively traversed to N levels, with cycle detection, etc. and the attributes merged roughly analogous to inheritance.

• Can only be implemented as a layer over IdAS

Examples of new (deep) search functions

Given DS A in context C find all other DSes with relationships to A. Parameters:

• [optional] min threshold of relationship level
• [optional] within context C or across "all" Contexts (whatever all means!)
• [optional] max of N degrees of separation (hops)
• [optional] sort by relationship/context or context/relationship

Given DS A in context C find other contexts Cn where Cn != C such that C contains DSes with a relationship to A

Given a DS A in context C return the union of all all attributes (and their values) of A by following all correlation links from A Parameters:

• [optional] max of N degrees of separation (hops)

Caching and Indexing

To enhance the performance of IdAS in situations where the underlying Context Providers do not support caching and indexing on their own, and especially those that maintain connections to remote data sources, an generic caching/indexing layer could be useful.

• Could be implemented either as a layer over IdAS or as a Context Provider

Schema/ontology mapping

A layer that maps from each source ontology to a specified target ontology. This layer could consume the existing IdAS API and support the this same API --performing the mapping as the value add between the two.

• Could be implemented either as a layer over IdAS or as a Context Provider

Authorization

A layer that acts as an authorization policy (e.g. XACML) enforcement point.

• Could be implemented either as a layer over IdAS or as a Context Provider

Emergent Contexts

Dynamically generate a new context and populate it with DSes correlated to their corresponding "base" DS such that the base DSes (in whatever context) share a set of attribute types (e.g. zipcode).

Dynamically generate a non-empty context by automatic clustering (any facet, any property, any context)

Identity Selector Selector

Requirements

1. Allow user on any platform to configure what selector they would like to be their default
2. Consistent UX on all platforms for setting/changing the default
3. Consistent API from browsers and local apps
4. Decouple browser <object> tag parsing from selector

See Also

• Higgins 1.0

Links

• Higgins Home