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

["Tom Doman" <TDoman@xxxxxxxxxx>]

Sounds like this warrants some investigation.  One of the goals for me
is to avoid having to create, associate, and then persist identifiers in
some additional store within the join context provider.  At the same
time, I'd like to be able to have a reusable identifier that can be
passed back into the join context provider and yield the same
amalgamated Digital Subject.  Hence, the discussion I had with Jim and
reply I made to Paul's message.

I'll look into the namespace extension point further to see if we could
take advantage of it for this.

Thanks,
Tom

>>> Scott Lewis <slewis@xxxxxxxxxxxxx> 7/25/2006 12:43 PM >>>
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