IdAS Registries Proposal

Introduction

This document describes a new approach to handling IdAS context provider registration, configuration, and identification issues. It builds on work discussed at the F2F in Provo Jan 2007. This document works top down from use cases.

It proposes a design that divides the registry work into two completely separate registries. One ("IdASRegistry") is a registry of context providers. The other ("IdASContextRegistry") manages the binding between a ContextId and a (ContextProvider, config-data) pair.

Definitions

• A ContextId (aka cid): An URI identifier of a Context. It may be an XRI. The intent is that cids are globally unique. In practice they may not be. Further, a cid holds enough information to resolve the appropriate (ContextProvider, config-data) pair needed to produce an instance of IContext.
• IdAS: An attribute service aggregator/abstraction. It manages a set of statically or dynamically installed Context Provider plugins
• A Context Provider (aka cp): (analogous to a JDBC driver) acts as a factory for IContexts. It does this by implementing support for interfaces in the org.eclipse.higgins.idas package.

IdAS Use Cases

1. Create a new (IContext, cid) combination. The cid was used to find the IContext. It acts as a name of the data of a specific Context.
   1. Need to be able to store an identifier in a CardSpace card which:
      1. Is enough to be used to open a context with a specific configuration
      2. Can be passed in an RST to the Token Service
2. Destroy a Context (by cid)
3. Connect to a Context (by cid)
4. Disconnect from a Context (by cid)

IdAS Non-Use Case

1. Associate a pre-existing Context that exists in some data store with a ContextId

Terms Used

• cid: short for "ContextId" (an identifier)
• factoryConfig: context provider-specific configuration data required to initialize the IContextFactory itself
• contextConfig: context provider-specific configuration data required to connect to, open, etc. an IContext
• cpid: id of a context provider (IContextFactory class name ? Eclipse extension id ?)

Key Interfaces

IdAS

IContext getConnect(cid)

IContextFactory

Much simpler than what we have now

IContext getInstance(contextConfig)

IdASContextRegistry

NEW: A registry of ContextIds (cids) and their associated (cpid and contextConfig) pair

void register(cid, cpid, contextConfig)

void unregister(cid)

cpid&contextConfig resolve(cid)

void initialize(URL)

IdASRegistry

IdASRegistry becomes much simpler than the currently implemented one

IContextFactory getContextFactory(cpid)

void registerContextFactory(cf)

void removeContextFactory(cf)

Implementation

IdAS Consumer Sample Code

The following are convenience methods (they might not really exist). These are things that an IdAS consumer would want to do.

IContext registerAndCreate(cid, cpid, contextConfig)
{
 IContextFactory cf = IdASRegistry.getContextFactory(cpid); 
 IContext c = cf.getInstance(contextConfig); now we need to add a new method to IContext to create backing data store
 IdASContextRegistry.register(cid, cpid, contextConfig); 
    above adds a new <Service/> section to the XRDS document pointed to by cid
 return c;
}

IContext connect(cid) the old create
{
 cpid+contextConfig = IdASContextRegistry.resolve(cid); // should return N "sections" and iterate?
 IContextFactory cf = IdASRegistry.getContextFactory(cpid);
 IContext = cf.getInstance(contextConfig);
 return IContext;
}

IdASContextRegistry

The main idea is that the implementation of this class would leverage code being developed by the OpenXRI community. This community is enthusiastic about working together with the Higgins project to integrate XRI registries and resolution.

The code we'd use to implment 'resolve' below is called an XRI Resolver. A java implementation is available at SourceForge here. It resolves to an XRDS document that contains metadata about various types of services. In our case the service type would be "Higgins IdAS Context Provider".

Here is what an XRDS document looks like:

<XRD>
  <Service>
    ...config data for a "Higgins IdAS Context Provider" goes here...
  </Service>
  <Service>
     ...altnerative contextConfig for another "Higgins IdAS Context Provider" 
        to same "back end" data source as above...
  </Service>
  <Service>
     ...info about some other service (e.g. OpenID server)...
  </Service>
</XRD>

The code we'd use to implement 'register' below would, in XRI lingo, be code to manage a "community" level registry (as opposed to the "top level" global XRI registry run by Neustar).

void register(cid, cpid, contextConfig)
{
 // if cid is an XRI, resolve it to a URL
 // HTTP get the XRDS document at URL
 // find the "Higgins IdAS Context Provider" service type within it
 // add cpid and contextConfig as "service metadata"
 // HTTP put updated XRDS document
}

cpid&contextConfig resolve(cid)
{
 // Glossing over a zillion details, here is what an XRI resolver does:
 // if cid is an XRI (i.e. it starts with "xri://") then resolves it to a URL
 // it does an HTTP get the XRDS document at this URL
 // lookup the "Higgins IdAS Context Provider" service type with it
 // return cpid&contextConfig
}

void initialize(URL) 
{
  // Set the "root" URL for XRI resolution. XRI resolution uses this URL
  // to tell it what registry service to use (well, to start at. XRI resolution
  // allows delegation to other registries too). 
  // Some deployments might want this to be "localhost" or a local registry 
  // running on a the local LAN. Others may wish to leverage the 
  // global XRI registry 
}

Open Issues

1. Pseudocode above doesn't (yet) address factoryConfig data usage and handling
2. Exact datatype of a cpid
3. Should cpid be a Java IContextFactory class name? or Eclipse extension id? Both?
4. Need component diagram of IdAS

Preliminary Conclusions

1. For simplicity, we are not going to support/recomend using N>1 <Service/> sections within the XRDS

See Also

• Yadis Specification. The Yadis specification provides:
  • A general purpose identifier for a person and any other entity, which can be used with a variety of services.
  • A syntax for a resource description document identifying services available using that identifier and an interpretation of the elements of that document.
  • A protocol for obtaining that resource description document, given that identifier.
• XRI Resolution Working Draft 11
• Higgins Home