As the editor of SAML 1.0 and someone who will be a panelist on the
Liberty panel at RSA next week the answer is DIX is solving a very
different part of the same problem space.
The principle point of SAML was to devise an open standard that allowed
an ERP application to hook into the enterprise authorization system. If
you look at most of the authorization products on the market you will
find that 90% of the code is essentially interface drivers to all the
1001 applications enterprises need to run.
Liberty is addressing a slightly different part of the same enterprise
federated identity space. In this case the identities being managed may
be consumer identities but the exchange of information is typically
taking place within a commercial context. Typical applications are
allowing a traveller to have a single unified frequent flyer membership
account that allows interaction with all the members of a given network.
This means that all the thorny issues of business rules etc have to be
considered up front.
What DIX is looking at is a much simpler problem. While some of the
companies involved are also looking to build enterprise strength systems
that may involve DIX and DIX protocols that is not where the working
group is starting from.
If you strip away all the fancy talk the problem and the solution here
are pretty simple. The only reson that it seems to be fancy talk is that
we are not yet familiar with the solution. It is exactly the problem
hypertext had before the web. I am sure that the Web would have been
invented five years earlier if hypertext had not had such a name for
hype.
The problem is that I have 100 od accounts at Web sites all over the
net. Each of these requires me to register separately and most ask me to
provide the same basic information. At the end I am left with the
problem of remembering all the accounts and passwords. Some people have
developed schemes for remembering the usernames and passwords but a much
better solution to the same problem would be to start with a single
identifier that represents 'me' at every site I visit [or multiple
identifiers if I choose].
At the moment there is some debate as to what that identifier should be.
Most people in the group are proposing it should be a URL. As far as I
am concerned we have an identifier already:
pbaker(_at_)verisign(_dot_)com
That's it. Now when I go to any site on the net I want to be able to
first give my universal user identifier. Then have some magic happen so
that I can safely authenticate myself against the universal
authentication service of the domain name specified in my identifier.
In order to use the identifier in the Web we will need to define a URI
scheme, I suggest dix:pbaker.verisign.com. Just as long as nobody
expects users to type in anything other than their email address (yes I
have given up trying to use a # mark as a separator to avoid spam). It
would also be polite to actually think about the I18N issues at the
start this time instead of afgter the fact like we usually do.
Here we have a bunch of proposals as to how this can work. Most involve
HTTP referal schemes. Some people are using HTTP digest. Others argue
that we should use SAML.
For example we might strip out the domain name component of the
identifier 'verisign.com' and then do a DNS lookup for a TXT record at
_dix.verisign.com which might list the DIX authentication protocols
supported by verisign.com. We can then do an SRV lookup to find out the
location of the servers for each supported protocol.
I am sure that the security area gurus will insist that the resulting
protocols will be proof against man in the middle attack and do not
result in passwords being exchanged enclair.
This is not a big problem, HTTP Digest did that in 1993 and if people
bother to read the earlier drafts you will find that it was even
proposed as a federation scheme back in 1996 at least. So any patent
troll hoping to make a few bucks by reading this message and rushing to
the patent office as has happened before is going to be disappointed.
Identity is a complex problem. What is being proposed here is to solve
one very small part of that problem. I believe that it is the critical
part however. Once you have a universal identifier all else follows.
I think that far from this being a doomed enterprise we will have
achieved significant deployment long before a WG is approved.
Like the Web this is something that should have been done years ago but
never happened because people did not understand the need. Who needs the
Web when you can get documents using FTP?
-----Original Message-----
I'm wondering what is the relationship of this proposed work
to SAML or the work of Liberty Alliance.
http://www.projectliberty.org/
I was frankly astounded that there is nothing in the Charter
Draft or associated documents that mentions the huge body of
work already existent on Federated Identity Management.
Could someone summarize the problem statement this proposed
WG attempts to solve, more specifically what is lacking in
existing Federated Identity Management efforts that the IETF
may have some relative expertise in solving?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf