IdAS Registries Proposal

Introduction

This document describes a new approach to handling IdAS context provider configuration issues (and more). 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.
• IdAS is an attribute service aggregator/abstraction. It manages a set of statically or dynamically installed Context Provider plugins
• A Context Provider (analogous to a JDBC driver) acts as a factory for IContexts

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 create(cid, cpid, contextConfig)

IContext connect(cid)

void disconnect(cid)

void destroy(cid)

IContextFactory

Much simpler than what we have now

cid create(contextConfig)

void destroy(contextConfig)

IContext connect(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

IContext create(cid, cpid, contextConfig)
{
 IContextFactory cf = IdASRegistry.getContextFactory(cpid); 
 IContext c = cf.createContext(contextConfig);
 IdASContextRegistry.register(cid, cpid, contextConfig); adds a new <Service/> section to the XRDS document pointed to by cid
 return c;
}

IContext connect(cid) 
{
 cpid+contextConfig = IdASContextRegistry.resolve(cid);
 IContextFactory cf = IdASRegistry.getContextFactory(cpid);
 IContext = cf.connect(contextConfig);
}

void destroy(cid)
{
 cpid+contextConfig = IdASContextRegistry.resolve(cid); 
 IContextFactory cf = IdASRegistry.getContextFactory(cpid);
 cf.destroy(contextConfig)  
}

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 config for another "Higgins IdAS Context Provider"...
  </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 config 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 below doesn't (yet) address factoryConfig data usage and handling
2. Exact datatype of a cpid

See Also

• XRI Resolution Working Draft 11
• Higgins Home