Re: [Auth]Identity Services Definition

[David Sugar]

This looks like a very nice summnation and interesting collection of 
information.  When one looks at single sign-on, I think the most 
important thing any trustable single signon system must provide is 
non-corrolative signon.  That is, if credentials are presented to site 
"X" that I am really user "A", these should not be common keyed so that 
if I go to site "Y", site "X" and "Y" can find out I am the same user 
and form a common profile of me behind my back even if I have chosen not 
to provide common identifying/corrolative information.

This is actually not an impossible challege.  A good authentication 
system need only be able to say to site "X" that this user "A" is the 
same user "A" as before, and say to site "Y" this user "B" is the same 
user "B", and without needing to provide any common data by using 
session unique identifiers that "X" and "Y" could then use to determine 
that "A" and "B" are the same.  If the user happens to reveal 
corrolative information to both such as a common credit card #, etc, 
well, there are limits as to how much any system can protect the freedom 
of those that cannot do so for themselves, but the authentication system 
should not in itself rat out the user at a fundimental level to those 
that wish to form global profiles of everyone, whether thru the absolute 
ignorant stupidity of having o0nly one authentication provider or a 
conceptually poor implimentation that reveals users over multiple 
providers thru the use of common data during authentication processing.

Adam Theo wrote:

> Hi, all. Started work on a "Definition of what makes up a complete 
> Identity system". Requirements, features, frameworks used to create 
> features, etc.
>
> However, I've hit halfway, but lost direction and focus. I started off 
> all organized, with the list: Addressing, Profiles, Authentication, 
> Authorization, Presence, Trust, Discovery. Then I realized that 
> Identity needed to run over a Transport, and often used a Subscription 
> framework to enable Presence and Profile subscriptions, as well as 
> Negotiation to automatically create agreements and find commonalities. 
> I've ended up with a jumbled list of subjects that I'm no longer sure 
> how they relate to each other or in a larger context. After all, 
> Subscription isn't so much a feature as it is a tool to make other 
> features. That's easy, but what about Authorization? I would easily 
> consider that a feature, yet it is used to protect Profiles and 
> Presence information. What about Naming? Is it a feature or a tool to 
> create features?
>
> This is what I have so far: http://www.theoretic.com/identity
>
> 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.
>
> What I first need is a truely complete list of features. 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.
>
> Thanks, all. I hope to turn this into a community project that will 
> help DotGNU Virtual Identities and my own Genio [ 
> http://www.theoretic.com/genio ] project with a clear direction and 
> focus.