dotgnu-auth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]Re: digital me too..


From: Cequs Inc
Subject: [Auth]Re: digital me too..
Date: Thu, 25 Oct 2001 10:53:17 -0400
User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

I think John hit it on the head with the mention of Novell's innovative
"Digitalme" , this is one of the paths that  Cequs has followed in
conjunction with any potential participants in this "identity convergence".

Personalize the network infrastructure instead of the current practice of
getting humans to adapt to servers. The need for a virtual root is evident
since it connects the different management domains.

Some other design points to consider are the current over reliance on the
"Facade" pattern, (Web Services)  when "Chain of Responsibility" and
"Memento" need also to be looked at.  Memento deals with private and public
interfaces, as well as an object which can retain state and be revisited.  I
call this a "statelet" and it is a replacement for a secure cookie, which
has tended to be web based or X11.

Chain of Responsibility indicates there can be handoffs to different modules
to get authentication and authorization. This decouples the need to
standardize on only one of many valid approaches in a legacy environment,
and promotes diversity. It should produce convergence, while allowing for
different protocols and products.

For example, I don't want to maintain two hundred different passwords for
two hundred different corporate web actors, plus keys, plus, tokens, etc.

Nor do I want to use the same password, secure cookie,  or algorithm for
all.  While Passport looks to manage this, and charge a toll to a "walled
garden" of affilated producers, I'm more interested in a global
authentication protocol which is applicable anywhere. This means paring it
down to what is minimum and acceptable.

To solve that problem, and others, I look to multicast "publish" my private
data to vendors who wish to "subscribe" to it. Instead of me subscribing to
their server(s) and putting in my personal data.  Of course they add value
if they cross authenticate me within a collapsed service area.

So companies subscribe to my "public" interface, which is managed with a
caretaker pattern.  As I change state, I revisit and update my memento
pattern through my private interface.  Instead of it persisting forever,
(it has a shelf life, has a ttl). As long as the record is in the root(s),
it remains persistent, if I choose to retire it, it goes away. This isn't
much different from DNS or PKI.

Unfortunately most systems here still tend to use things like SSN, which is
a bad thing, so the idea is to reduce the amount of persistent personal
info, to the extent possible, and still meet the requirements.

What the root does is supply "knowledge routing" or "superior knowledge" to
another server which actually holds the information. Since the Cequs virtual
root can map various types of information, the transfer of the information
can take place, even though all actors do not use LDAP as a common
interface, (although the set of protocols surrounding LDAP make this
protocol) very attractive.

In addition, different management domains exist, each with it's set of
affiliates which agree to be managed. Though a federated set of those
management domains, a superset is derived which can communicate at country
level, such as c=US, or Cequs, to the world root. The manner in which the
roots communicate (such as X.500 (2001), LDAP, security XML,  really doesn't
matter to the end user. Yet the data does need to be agreed to at some level
to make it useful.  The interface is wide at the user end, and narrow when
it is constrained between root participants for efficiency. The type of
interface at the user end can be extremely varied, as long as it meets the
requirements, with the management domains acting to accept and translate the
data into something the backbone system understands.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]