[cross-posting]
Would this have any value to the
Container-Repository?
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On
Behalf Of Scott Lewis
Sent: Tuesday, July 25, 2006 2:44
PM
To: Higgins (Trust Framework)
Project developer discussions
Subject: Re: [higgins-dev] Unique
Identification of AmalgamatedDigital Subjects
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
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
