Re: [higgins-dev] Unique Identification of Amalgamated Digital Subjects

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Paul/Higginsers,

Paul Trevithick wrote:

We have agreed that there is at least one "unified" namespace of identifiers
within a Context, namely, the CUID (contextually unique identifier
namespace) that we've been talking about here. There may, however, be other
identifier namespaces managed by a single Context as well. 
  

There might be a good cross-project coordination point here.

ECF has defined an extension point (org.eclipse.ecf.namespace) that allows providers to define their own Namespaces...delegating to them the responsibility for creating IDs (instances of interface org.eclipse.ecf.identity.ID).  In ECF, ID instances are then used to uniquely identify services (e.g. irc://slewis2@xxxxxxxxxxxxxxxx) and/or persons using those services (e.g. ircuser:slewis), and/or objects (e.g.  objectid:org.eclipse.ecf.example.collab.chat) within the given Namespace (irc,ircuser,objectid). 

ID instances are:

1) guaranteed (by contract) to be unique within the given Namespace
2) extend java.security.Principal (all IDs are Principals)
3) implement Serializable
4) implement a method toURI() which returns URI (so can also be URI)

See org.eclipse.ecf.identity.ID for all the methods on the ID interface but you've already seen most of them.

There are 'built in' providers for creating IDs from arbitrary strings (StringID) and SHA1 SecureRandom numbers (GUID).

Then at runtime ID instances are created with the following (e.g.):

IDFactory.getDefault().createID(namespace, uri);
 or
IDFactory.getDefault().createID(namespace,String);
 or
IDFactory.getDefault().createStringID(String);
 or
IDFactory.getDefault().createGUID();

All of the code for the Namespace extension point, ID interface, and these basic provider implementations is in the org.eclipse.ecf plugin, in the org.eclipse.ecf.identity package.  It's trivially small (11 classes), and has worked extremely well for representing ECF service/protocol identifiers from irc, to jxta, to xmpp, to zeroconf, to jms, etc.

This extension point may be useful for some of the things under discussion...and of course all of the work is available to Higgins/any other eclipse project.  It's worked flawlessly for us so far.

Context Providers which provide amalgamated identities
could emit unique identifiers with a variety of name forms for a given
set of Digital Subjects.  The wiki talks about the constituent players
of the US Tennis Team.  In a joined system, I may end up with Digital
Subjects which are uniquely identified in a variety of naming forms
(X.500, RFC822, GUID, Screen Name, etc.) for the constituency of that
team.  Ultimately, identifiers are presented to end users.  
    

As I mention above, in a single joined context there may be multiple
identifier namespaces (what you call naming forms). We only require that one
of these be the CUID namespace. The other identifiers for the same Digital
Subject may or may not also be uniquely identifying.
  

With ECF's definition of Namespace, the provider implementation (subclass of org.eclipse.ecf.identity.Namespace) defines the characteristics of the given Namespace...i.e. how 'wide' the scope of uniqueness is (from minimally unique to globally unique).  This may be a useful concept for issues under discussion.

Scott