dotgnu-auth
[Top][All Lists]
Advanced

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

Re: [Auth]Identity Services Definition


From: Albert Scherbinsky
Subject: Re: [Auth]Identity Services Definition
Date: Tue, 01 Jan 2002 11:45:32 -0500

Hi Adam,

Adam Theo wrote:
> I need a new direction and new ideas. I started off thinking it would be
> an easy list of features, but I'm realizing there is alot more to an
> Identity system than it's features, and I'm struggling to figure out how
> to organize it all.

I remember several months ago when the dotGNU authentication
project was getting off the ground and people were saying
that it might be hard to get people to work on it because it
wasn't all that challenging or interesting. Personally at
the time I found these statements a bit odd. I have been
working on developing the simple single login concept and
have found it very interesting and challenging. Reconciling
the apparent paradox between convenience and security is to
say the least damn hard. People look at the simplicity of
the SIML and PIBX specifications and think, "That's simple,
but how do you make it secure?" or "That's simple but how do
you make it location transparent." My response is, that's
what makes the problem interesting and challenging.

> What I first need is a truely complete list of features.

This is a noble goal but you would be better off starting
with a problem definition and a requirements document.
Otherwise you are just defining things out of thin air. My
approach is not to fixate so much with complete definitions
for things apriori(ahead of time) but to try things out and
then define them once they work. Which comes first the
concepts or the realization of those concepts? What has
worked for me in the past is to alternate rapidly between
these two modes. This has a name by the way, it's called RAD
Rapid Application Development.

1. Conceptualize a little bit. (write down the problem)
2. Realize a little bit. (imagine some possible solutions.)
3. Conceptualize some more. (write a requirements document)
REPEAT_IF_NECESSARY {
  4. Realize some more. (pick a possible solution and build
a prototype)
  5. Conceptualize some more. (document the problems and
virtues of your prototype)
  6. Realize some more. (Fix the problems or start over with
another possible solution)
}

 Should I make
> "Single Sign-On" a feature, or keep it as a sub-issue of Authentication?
> Issues like this need to be resolved, and I need your help. Could
> everyone here help me? First by making a complete list of features of a
> "complete" Identity system? By complete I mean "requirements and
> options", "everything possibly relevant". We can take the next step from
> there by looking at the relationships between the various features.

The answers to your questions depends entirely on how you
define the problem.
For instance, for me I happen to be working on Single
Sign-On as an end to itself.
So for me, it is not a feature but an application. However,
if one were working on something grander in scope like a
Distributed Operating System one might consider Single
Sign-on to be a feature of that Distributed Operation
System. There are advantages to conceptualizing
Single-Login(single-sign-on) as an application apart from
the scope of ones larger endeavor. One of these being that
if one allows for the notion that Single-Login is just a
feature of an operating system it opens the door for large
hegemonistic corporations to further leverage their existing
monopolies on the desktop to the NET. Thinking of Single
Login as an application allows for it's implementation on
existing operating systems like Windows without access to
it's source code.  More importantly, Identity is something
which is owned by the individual not by the companies which
seek to exploit it, to their own ends. If there were a
Constitution of CyberSpace ownership and complete control
over ones own identity is something that should be enshrined
within it.


Regards, 
Albert Scherbinsky
Drop by at: http://members.rogers.com/alberts/

Convenient control of our personal information:
Single Login:
http://members.rogers.com/alberts/single.htm
Simple Interface Markup Language:
http://members.rogers.com/alberts/siml.htm
Personal Information Base XML
http://members.rogers.com/alberts/PIB.htm


reply via email to

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