> From: John Merrells [mailto:[EMAIL PROTECTED]
> For sure, the tech should be under the covers, and the user's > should just experience the benefits. But, I've never > experienced the benefit of SAML on the web. Nick's big list > of deployments suggests that I would have to be a Boeing > employee who banks with Wells Fargo. Possibly, but this is simply a consequence of the way that network protocols are deployed. To get traction you have to aggressively court a tightly focused early adopter community. That does not mean that the protocol is only designed for that community, it does mean that you are most likely to find early adoption there. Obviously we were not designing a single sign on scheme for the blogosphere in 2002. Most of the companies who showed up for the SAML kickoff were vendors selling enterprise class products or services. That is where the market was in those days. From the very first meeting it was apparent that there was a huge number of people involved, 60 to 80 in the first WG meeting. There was thus a very understandable desire to try to keep the scope tightly focused. I think that DIX is doing something different but it can certainly be something complimentary. I would like DIX to reuse components from SAML and WS-* wherever that makes sense. If DIX is going to be used with attributes supplied by trusted third parties then DIX code is going to have to accept attributes in the form(s) supported by the commercial TTPs. At this point the only formats that I am aware that commercial TTPs support or are planning to support are X.509v3 certificates and SAML assertions. > I think there clearly is a technology issue here. With the > SAML protocol I don't see how you move a token between > parties who don't already have a pre-existing relationship. That depends on how you configure the system. The SAML spec sets out a series of use cases that the spec is designed to support. That does not mean that they are the only use cases the spec supports as written. There was quite a bit of argument over which use cases should be included, more argument than we had over the protocol design which was taking place independently. SAML is designed to support a strong federation model where the user, the authentication service and the relying party can interact according to many different accreditation models. In DIX the problem of establishing trust between the authentication service and the relying party is essentially finessed by reducing the problem to a single communication pattern. Given where we are starting from I think that the most likely response from the IESG here is going to be 'go write a requirements document', it is certainly what I would request if I was making the decision and was not otherwise involved. I would then want to see a demonstration that each piece of new mechanism required in DIX is justified by a clear need. I think that there are clear justifications for certain DIX innovations: * The SAML assertion format is designed to support signed assertions using XML Signature. The overhead required is certainly justified when dealling with TTP assertions where the attributes are trusted and must be trustworthy. URI form encoding is much simpler and easier to manage and equally useful when the data is originally self asserted. * The use of a uniform identifier for identity is a key architectural innovation. SAML supports the use of a uniform identifier but there is a huge difference between support for a feature and designing a system around a feature. When WS-* was first introduced people were determined to see a competition between the two. Today most people agree that there is a need for different approaches for different applications. WS-* is essentially a no-compromises system designed to provide the best possible security infrastructure for Web Services. It can also be used for other purposes and used standalone but the architecture does not make concessions that are designed to encourage early adoption for that application. The objective here is to establish an open identity system for the Internet. DIX, SAML, WS-* are merely means to that end. I am quite happy if it turns out that the output of DIX turns out to be a protocol that is mostly used as a transitional technology; a scafolding that allows the more ambitious schemes to be built more quickly. _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
