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 ?)

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
      3. Context Config Sample
2. Interrogation/Instantiation
   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
3. Listing all available CPs
4. Listing all available cids

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:

Producing an IContext from a cid

1. The IdASContextRegistry is used to locate the cpid and contextConfig from the cid.
2. The IdASRegistry is used to produce an IContextFactory from the cpid
3. The resulting IContextFactory is used to produce an instance of IContext from the contextConfig

Key Interfaces

IdAS

IContext getContext(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 unregisterContextFactory(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.

/**
 * These are the steps one would need to take to produce
 * an IContext instance from a cid
 */
IContext getContext(cid)
{
 cpid+contextConfig = IdASContextRegistry.resolve(cid);
 IContextFactory cf = IdASRegistry.getContextFactory(cpid);
 IContext = cf.getInstance(contextConfig);
 return IContext;
}

/**
 * Something like this could be used when bootstrapping 
 * a new IContext instance, especially when it has yet 
 * to be configured with backing data
 */
IContext createAndRegister(cid, cpid, contextConfig)
{
 IContextFactory cf = IdASRegistry.getContextFactory(cpid); 
 // Or maybe getInstance takes a different form of config data in this case, 
 // and maybe there could be a way to then ask the IContext for the configData
 // which will be used to register.
 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;
}

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.

The types of Services are defined by <XDI.org???(certainly not Higgins!)>. Examples would include:

• OpenID Server (exact type string is "http://openid.net/server/2.0")
• JNDI/LDAP Context Service

Here is what an XRDS document looks like:

<XRD>
  <Service>
    ...config data necessary for a Higgins JNDI/LDAP CP to connect to open this Context. 
  </Service>
  <Service>
    <Type>http://openid.net/server/2.0</Type>
    <URI>http://myidp.com/server</URI>
  </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).

Questions from Jim:

1. Does this require HTTP, or can this all exist on an isolated machine, running no HTTP stack?
2. Do we create the "Higgins IdAS Context Provider" service type when it doesn't yet exist?
3. Is contextConfig raw XML, or a DOM document (or similar)?
4. Since initialize(URI) sets a root URI, does that mean the cid only contain some kind of relative path?

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. Exact datatype of a cpid
   1. Should cpid be a Java IContextFactory class name? or Eclipse extension id? Both?
   2. Needs to be resolved in order to implement
2. Pseudocode above doesn't (yet) address factoryConfig data usage and handling
3. Need component diagram of IdAS
   1. One box shows core IdAS interfaces
   2. One shows IdAS toollbox
   3. One shows Registry-related code

Preliminary Conclusions

1. For simplicity, we are not going to support/recommend using N>1 <Service/> sections which are resolved to by the same cid 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