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@xxxxxxxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf