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, contextConfig) pair needed to produce an instance of IContext.
• contextConfig: context provider-specific configuration data required to instantiate, open, etc. an 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.
• cpid: id of a context provider (IContextFactory class name ? Eclipse extension id ?)
• factoryConfig: context provider-specific configuration data required to initialize the IContextFactory itself
  • Do we need this?

Use Cases

1. Registration
   1. Of a CP (specifically of a CP's factory with a CP registry)
      1. Programmatically
      2. Manually
   2. Of a cid (along with contextConfig)
      1. Programatically
      2. Manually
2. Interrogation
   1. IdAS consumer has a cid, and needs an IContext instance.
      1. This cid must convey enough information to be used produce an instance of IContext with a specific configuration (contextConfg).
      2. This cid must be able to be passed in an RST to the Token Service via CardSpace

Out Of Scope Use Case

1. Creating a new IContext instance which has no associated backing data.
   1. Associating an IContext instance having no backing data with backing data
2. Programmatically creating a new instance of contextConfig data

Overview of Solutions

Registration of a cid

Each cid will be registered inside an XRDS document. XRDS documents contain metadata about various types of services. In our case the service type would be "Higgins IdAS Context Provider". Each instance of this service type would represent a specific Higgins Context. It will hold the information needed to instantiate an IContextFactory, as well as configData to be used in instantiating an IContext.

Programmatic Registration of a cid

Assuming the cid, cpid, and contextConfig are already known, one calls a register method of IdASContextRegistry. In turn, IdASContextRegistry locates the appropriate XRDS document (using part of the cid), and adds the appropriate service (as specified by the remaining part of the id, along with the cpid and contextConfig).

Manual Registration of a cid

The appropriate XRDS document may be manually edited to create "Higgins IdAS Context Provider" service elements. The format is XML.

Registration of a CP

TODO: Do we want to continue what we're currently doing? Do we want to move away from overloading the java security algorithm provider model?

Programmatic Registration of a CP

TODO:

Manual Registration of a CP

TODO:

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. i.e. an IdAS ContextId
  • A syntax for a resource description document identifying services available using that identifier and an interpretation of the elements of that document. i.e. an XRDS document
  • A protocol for obtaining that resource description document, given that identifier.
• XRI Resolution Working Draft 11
• Higgins Home