[Foundation] Identity! (long post)
adamtheo at theoretic.com
Tue Jul 10 04:11:03 CDT 2001
Hello, Adam Theo here;
This is going to be a pretty big post, I feel. Sometimes, on big
issues I just sit back for a little while and follow it,
digesting. Then spend an entire night working on a "Mother of all
Posts" to address it all at once. This is going to be one such post,
addressing the issue of a Jabber-based Identity system. It is BCC
posted to the Jabber Foundation list <members.jabber.org>, the Jabber
Development list <jdev at jabber.org>, and the Jabber Identity project's
own list <identity at theoretic.com> which is hosted by my website,
Theoretic Solutions <http://www.theoretic.com>.
This document was written in conjuction with Mike Hearn, who is taking
over the co-ordination and public relations of the Identity project
(at least for Theoretic). Please provide any feedback to either him
<mhearn at subdimension.com> or me <theo at theoretic.com>, or even to this
list, if you feel anyone else can benefit from hearing your opinions.
I would first like to thank everyone for the huge interest in this
topic. It is good to see such activity and discussion, and flow of
ideas. I feel I again should strongly encourage everyone interested
(to develop and critique, all are welcome) to subscribe to the Jabber
Identity's own mailing list at Theoretic by sending to
<identity-subscribe at theoretic.com>. No subject or body needed, just a
FROM header. It has been a low volume list before taking it public,
but I do not expect that to change much even now. Besides, any large
amount of activity that you may be worried about will pass as soon as
we settle down in it. And just to note, the list *could* be
temporary. If this system is fully adopted by the Jabber community and
Foundation, I may be subject to intense peer pressure to move it from
Theoretic.com to Jabber.org, much to my ego's dismay :-)
There is an archiving feature for Theoretic's list. A warning: I have
never used it, but I am sure it will work. To get an archive of a
message, you must include the message number in the email address. The
formay is <email@example.com>, where ### is the message
number (such as '1', for the first post, or '19' for the 19th, and so
on...). For example: <identity-get.19 at theoretic.com>. I am not aware
of any way to retrieve all messages at once, other than sending a
single email CC'ed to the many 'get' addresses. I believe, but am not
sure, that you need to be a subscriber to get these archives, so I
would recommend you subscribe first.
Mike Hearn was good enough to set up a JabWiki with Mr. Gottschalk's
JabWiki system <http://jab.sirlabs.com/bin/view/JIGs/JIS/WebHome>. I
will admit I was apprehensive of it at first, but now agree completely
that it should likely be the project's development home. What turned
me around was seeing it's strong support from the community, and that
was enough to counter my dislikes and fears. This website will be used
from now on by Mike, Eric, myself, and likely anyone else who wants to
participate in the development to hold propositions, drafts, changes,
JabWiki is good for developing, but I have to be honest, is not user
friendly at all. So therefore I think we should use the webspace I had
set up a while ago at Theoretic <http://www.theoretic.com/identity>
for it's public website. This would be the website for final releases
and education about the project, as well as helping the public contact
the developers. There is currently very little (if anything, I can't
remember) located there, but if you have something for the public,
send it to Mike or myself (Eric is on vacation right now). We can
upload it for you.
(oh, yeah. KISS just came on the radio. this is going to have to pause
for a few minutes... ok, back :-)
There are many authorization and even identity systems built and being
built, as well as much discussion and media on them and the
technologies in general. The fight for control or liberation of user's
identities and personal information on the Internet is fierce, and
only growing fiercer.
There is a complete list being built of all other systems and articles
and discussions about all of it. It can now be found at
Our vision is to create a very scalable, dynamic, and open system for
holding and managing personal information on the Internet.
* Such a system should be free and open at it's core and highest
levels while allowing for plenty of proprietary and closed
opportunities in lower levels of the system.
* It should finally allow the user complete freedom and control over
their personal information on the Internet while being very corporate,
government, and entreprenuer friendly.
* It should be very user friendly, being intuitive and simple to
understand, while being very powerful and flexible for the services
and servers that would be implimenting it.
* It should not follow or lead a philosophical doctrine. This is pure,
reasonable, fair, and well thought out technology.
We are providing these rough draft definitions to clarify and guide
this project through all stages of it's development.
* Identity: Identity is a another representation of your online
person. In the same way that Presence is a representation of your
current online state, Identity is a representation of your online
data. It is a set of profiles and services that represents personal
information about you, associated with your JID. This definition of
'identity' does not include distributed computing (such as Microsoft's
new .NET plan), or even web services (such as Microsoft's HailStorm
framework). Continuing with using Microsoft products as examples
(simply because I bet they are the most familiar to everyone), this
system can be most closely compared to Passport, although at this
early stage is closer to the (non-Microsoft) vCard spec.
* Profile: A profile is an XML datastore and represents information
entered by the user. A profile is free-form, it can normally take any
information at all and is the equivalent of an XML scratch-pad in
which a user may enter information. The only restrictions in place are
so Profiles can be rendered on screen as a webpage, or in a client -
so for instance datatypes may be restricted. However, Profiles can be
associated with Schemas, in which case certain information MUST be
present, otherwise the Profile doesn't conform to the Schema and is
* Schemas: A schema is a definition of the layout of a
profile. Similar to a DTD but not using the syntax (we may define our
own schema syntax or use the W3C 's XML Schema spec). Schemas can be
created by the Jabber foundation or by 3rd parties. If a Profile is
associated with a Schema, that means that the profile MUST have the
information defined by the schema in it. It can store other
information as well, but it has to have the structure defined by the
schema in it.The reason for the use of schemas is to impose
organisation onto Profiles. If you know that a user has a profile that
conforms to the "Location" schema, then you can use that information
to automatically fill out parts of an order form for example, or to
search for users based on country etc. To allow for searching
(remember that the reason I'm working on this system is so I can meet
nice girls :) Schemas can be submitted to the JUD which will then
allow people to search on particular items in the schema. This will
allow me to search for people near me who share my interests for
* Security: The relationship of identity to security recently came up
in the Jabber Foundation list. Mr. Sutton wished to include this
Identity project into the Security-related Jabber project. It seems to
have been decided that although Identity will heavily *use* security
measures, of course, it is not *a part of* security any more than
bread is a part of blueberry jam.
Below are some possible benefits to a general identity system,
although certainly not all. I would like to hear everyone's ideas of
what can be useful and good about an identity system. Our
implimentation of such a system should try to maximize these benefits,
while keeping security and back-end flexability in mind.
One benefit of an identity system is the holy grail of "one account
for all websites", where the status quo of multiple usernames and
passwords for various web and net services is eliminated and these
services would use this one central account instead. This increases
user convenience, but only if the process of logging into this
universal account is as easy or easier than it is under the status
quo. Once we start making this even slightly more diffult by adding
steps and measures, we will fail.
Another benefit is the user being able to manage and control who has
access to this information at all times. No more forgotten accounts
coming back to haunt you with spam or claiming you already signed up
when you can't remember your old username or password.
Using this, a user can limit access to this information to only those
services they want, and remove permission to access (and therefore
their account) at any time. No more complicated unsubscription or
account closing procedures to follow at websites or through email. It
is all done from one place using a standard system.
Overall security can be increased. Once a single account manages
everything, and the user can limit information as they see fit, using
only secure connections for all transactions can be more easily
assured. Automatically refuse all requests for information that do not
come over a secure line, and since your 'bank' of information is on
one system, you can more easily verify it is secure, instead of
tracking down the security of every service you have an account with.
RELATIONSHIP WITH .NET & ALTERNATE SYSTEMS:
The idea of distributed computing and software as a service has been
floating around for a few years, but it wasn't until Microsoft
unvieled their .NET Initiative that there has been such a flurry of
activity about these ideas. This is in good part due to the fact
Microsoft is viewed as the 'Evil Empire' of the computing and internet
worlds, unlike Sun, who was often viewed as more or less market and
community friendly, or at the very least not as evil as Microsoft. As
such, many people in the Open Source and Free Software communities of
the Internet are deicating themselves to make alternate systems.
Our official position towards Microsoft's .NET and other, alternate
systems are the same: "We think the concepts of distributed computing
and software as a service are just as good for progress and the
Internet as the current models are. As such, we are eagerly watching
and investigating these systems to find any that fit our needs and
visions and is technically sound enough to work with. We hold no bias
towards Microsoft or the corporate Internet at all.".
RELATIONSHIP WITH HAILSTORM & WEB SERVICES:
Web services have been gaining attention and interest in recent
months, and promise to revolutionize the World Wide Web as much as
dynamic and database-driven websites did in the late 90's.
Our official position towards web services in general is one of
eagerness for this new technology to become stable and
standardized. Our position towards Microsoft's HailStorm is very
different from web services in general and their .NET
Initiative. Since HailStorm is completely dependant upon Passport, a
technology and system which we deem to be very insecure and bad for
users, we are opposing HailStorm and especially Passport. It is not
out of a bias towards Microsoft that we do this, it is simply because
Passport (and therefore HailStorm) is very weak and inferior to what
can be easily done.
RELATIONSHIP WITH JABBER:
This system is obviously going to use Jabber in some way, since not
only is the name in it, but everyone involved in it so far has agreed
that Jabber provides an excellent mix of technologies for us to work
Hopefully this project will become an official Jabber Foundation JIG
(Jabber Interest Group), in which case the political relationship will
be as close as the technical one.
We now describe in detail how we plan to impliment such a large and
powerful system. We have all agreed unanimously how the personal data
is to be stored, and also the means by which the user will control the
access to and use of the data. However, we do have a few widely
differing plans on how this data is to be accessed by the service. All
of these are discussed below.
The first stage of the proposed Identity implimentation would be to
design a set of structures by which the data will be stored. They will
likely be in the form of XML schemas, and would be simple and basic in
the testing stages, and then be developed further when we have the
test system working.
The next stage of the implementation would be to design and write a
module for the server that allows for structed storage of data
contained in 'profiles' in the user's Jabber account. Profiles would
be created both by the user and possibly by services that have the
user's permission to store data in their account.
The data stored in profiles would be structured according to the above
mentioed schemas, documents that describe the layout of the
data. Profiles based on schemas would allow clients to build user
interfaces from those schemas. At first we envision that the client
would take the form of a dynamic website, run by CGI scripts. This is
because the necessary "GUI generation from profile" code would be
fairly complex, and as such it'd probably be easier for clients to
simply redirect to a website passing the JID on the URL string. The
website would then present the users information in the web browser a
la MSN Messenger.
However, this does not mean that clients also could not provide their
own GUIs for identity profiles. This would rely upon the Jabber Forms
specification being worked on by another interest group.
Profiles may be associated with schemas, in which case the information
stored in that profileis structured can can be searched upon,
manipulated etc. But, if a profile doesn't have a schema, that doesn't
make it any less of a profile, it just means that it can only be
manipulated by the specific service that created it.
The system would eventually allow for custom schemas, not hard coding
the XML structure to be used directly into the system. This would
provide great flexability and customization for the server
admin. However, it may be better to start out actually hard coding
such an XML structure into the system, since this would be easy to put
together, and still very effective. It would be later, when we have
the basics of the system working, that we would incorporate the
ability to define your own data scructures. This should be discussed.
Using the custom defining of schemas, profiles would be accessed via
the IQ mechanism. For instance, an IQ get on an account, with
thejabber:identity:profiles namespace would retrieve a list of the
profiles that a user has filled in. Other IQ gets could then retrieve
those profiles, or particular fields from thoseprofiles. In a similar
vein, IQ sets would be used to store the information.
The benefits to the custom schemas is obvious: much greater
flexability and specialization is possible. However, it is important
to note the drawback is the above step of needing to get a list of
profiles, as well as the chance of 'balkanization' of the system from
incompatible XML schemas. Both of these are relatively small
considering the small amount of resources taken up by the extra step
and the social trend away from balkanization in most situations, not
The user will be able to control which services can access what data
(postal address, birthdate, bank account information, hobbies and
interests, etc.), how they can access it (only over a secure SSL
connection, etc.), and when they can access it (any time, only after
first getting express approval from the user on a case-by-case basis,
Only services that are allowed by the user can access private
information (the user can make some information public, where anyone
can see it, such as name and gender, for example). These allowed
services are said to have 'permission'.
To have permission, a service must be listed in a user's service list,
which you can think of as a Roster of services instead of contacts as
in the rest of Jabber. Also, a service must be filed by the user under
an 'identity zone', which you can think of as Groups of services
instead of contacts as in the rest of Jabber. A zone is labeled by the
user, and they can have as many as they want. Under all proposed plans
below, a set of rules and filters are associated with each Zone. These
rules set privacy and access controls, such as only being able to
access credit card information after getting express permission from
the user on a case-by-case basis, or only being able to get this
information over a sufficiently encrypted and secure connection. When
a service tries to access data, the user's server holds the service to
the rules associated with the Zone they are filed under.
At any time a user can add, modify, or remove a service from a Zone or
the List entirely. This can be used as an easy way to 'un-subscribe'
or cancel accounts with services. When the service tries to access the
data the next time, they can be given a notice that asks for
cancellation of the account with them.
Also, this is a powerful way to regulate and control one's
privacy. Privacy rules can be included in the system which act as
personal 'contracts', telling the service how the data can be used and
stored on their systems. Of course, for this to work, the privacy
contracts and agreements would have to follow a machine readable
format, possibly the P3P devised by the W3C?
The above implimentations of storage and control are all agreed upon
and pretty much set at this point. The concepts behind them are
excellent and well thought out, we think. Everything else, however, is
still open to discussion. Below are outlines of four plans that can be
discussed, developed, and discarded by the Identity JIG.
The first is a system that uses tickets, which I call the "Ticket
Plan". It is detailed at
runs similar to Passport, but there are many significant
differences. Here is a run down.
* User goes to Service (website or application) XYZ. They give XYZ
* XYZ does an 'iq-get' on JID for the user's 'trusted authority',
which could be their bank, ISP, Jabber provider, etc.
* After getting trusted authority (call it ABC), XYZ re-directs user
to ABC website, passing along JID as well.
* ABC asks user for Identity/Jabber password. User enters it.
* If true, ABC creates a 'ticket', which is just a hash of random
* ABC logs into user's JID and sets the ticket in the user's identity
profile. ABC also sets what info can be accessed using this ticket.
* ABC then sends user back to XYZ, passing ticket as well.
* XYZ takes ticket, does another 'iq-get' on user's JID, using ticket
as a password.
* User's jabber server verifies against tickets in identity profile.
* If match, jabber server returns info allowed by ticket to XYZ.
* XYZ can save ticket as cookie on user's browser, for permanent
I think this plan is powerful and is most likely to be trusted by
large services such as IBM and Bank of America.There are two main
possible flaws with this plan, however. One is it has a lot of steps
to it. The more steps, the more time the user and servive will sit
waiting for the process to finish. Also more chances for error and
security to be compromized. The second is that this plan does not
handle non-website services very well. For instance a local
application a user has downloaded and installed. The service must
direct the user to a web browser for them to authenticate themselves.
The second plan that has come up uses real-time instant messaging to
make sure a person is who they say they are. It is introduced at
<http://jab.sirlabs.com/bin/view/JIGs/JIS/ImmerPlanDraft>. Here is the
* The user visits XYZ.
* User gives XYZ their JID (either through form, cookie, built into
* XYZ sends a 'verification message' to user's server.
* Server can format it using user's configuration (add some info from
the Better Business Bereau database, do/do not inlcude XYZ's Privacy
* After any configuration, server sends message on to user.
* If user is logged into Jabber system, can get verification message
as instant message. If not, can get it by email or be redirected to a
special verification website set up by the user's server.
* User can reject/accept request from XYZ.
* User can also set rules for XYZ to abide by when getting information
* If accept, server tells XYZ user is verified.
* XYZ can then get information with 'iq-get' enforced by rules from
I think this plan is fast, easy to impliment, and easy for the
user. It is also pretty secure, since no one ever has any passwords
and few people ever handle the data. There is one flaw, however. It
may be extra intensive on the jabber/identity server, with all of this
processing and collecting of data. Maybe ways can be found around
this, using even simple caching and minimalist data structures.
The third plan potentially doesn't even need Jabber, and is described
at <http://jab.sirlabs.com/bin/view/JIGs/JIS/SimplePlanDraft>. Here is
* User gets an identity account.
* User sets Zones and rules in identity account, and with each zone, a
* User gives service XYZ their identity name (JID) and the password to
the Zone they want the service filed under.
* Service connects with user's identity server, and presents
* Server compares password to Zones in user's account. if a match,
server files service under that zone.
* Service can now access the data allowed to it by the Zone.
This system can work equally well from a web browser or a locally
installed application. it is very easy to impliment, and easy to
understand. However, it lacks in power and has little way to enforce
Mr Norbert Bollow presented a rough idea of a client-side
authentication system on the DotGNU Developer's list. He proposed
having all files and data kept on the client's PC, using the greatest
extreme of the 'edge computing' model. He presented that this data's
natural home would be on the local machine of the user, and I assume
it could be synchronized with a remote machine upon the user's command
when he will need to shut down his computer or go away on
vacation. You could take this model and extend it into the P2P
realm. Perhaps a 'Identity client' would reside on each user's system,
and would enable other clients (note: no servers) to access data
stored on the local computers.
This plan presents some interesting ideas, and some things to
certainly think about. However, it's strict adherance to client-side
storage presents many hinderances. I like the way Jabber does a
client/server system, but if a system wants to emphasize a truely
'secular' or 'peer-equal' system, then something based off of this
would be ideal.
STAGES OF DEVELOPMENT:
* Basically, Identity was primarily conceived to replace the vCard
system of Identity currently in use in Jabber. As such, the first
stage will be to define a way of storing and retrieving personal
* The next stage is the implementation of Passport-like
authentication/storage systems, to allow the Jabber account to be used
with websites and applications.
* Then, we should build a distributed JUD which can store and index
Identity information. This will provide us with one of the most
powerful means of searching for people ever invented!
* Finally, a set of Hailstorm like services built on top of
Identity/Jabber which would directly compete with said MS
initiative. However, we are a long way from this, and our primary
concern is a replacement for vCard.
-- Adam Theo >> "Fairness Above All!"
/\ Theoretic Solutions (www.Theoretic.com):
//\\ 'Activism, Software, and Internet Services'
// \\ Personal Homepage (www.Theoretic.com/adamtheo/):
//----\\ Email & Jabber: Other:
//--||--\\ -Professional: theo at theoretic.com -AIM: AdamTheo2000
|| -General: adamtheo at theoretic.com -ICQ: 3617306
|| -Personal: adam at theoretic.com -Phone: (850)8936047
|| "A patriotic libertarian buddhist who loves technology,
|| free market capitalism, and Reese's peanut butter cups."
More information about the Members