> 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. I disagree. SXIP (nee DIX) is overall attempting to solve essentially the same problem space that the SAML web browser SSO profile addresses. The extra aspects defined in the DIX I-D, which are largely various named attribute-value pairs, could be defined on top of the SAML web browser SSO profile (see saml-profiles-2.0-os.pdf at http://docs.oasis-open.org/security/ saml/v2.0/). Hence many of the questions and objections raised on the DIX list in terms of "why reinvent the wheel??". > The principle point of SAML was to devise an open standard that allowed > an ERP application to hook into the enterprise authorization system. That's incorrect. I was there from the beginning too. We did not do any special tailoring of the SAMLv1.x specs to make them particularly complementary to any particular form of web-enabled app. Any vanilla website can be SAML-enabled by dropping in one of a plethora webserver plugins available from F/OSS sources thru your friendly for-profit software vendors. > 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. This is also incorrect. The early liberty architecture overview did attempt to illustrate the problem domain with cross-business-enterprise examples, for better or worse (I, by the way, wrote that doc), but there is *nothing* in the protocol specifications that limit their applicability to strictly business contexts. > 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. This can be accomplished using SAML. SAML, as you note, doesn't stipulate a particular identifier format. However, it is a small matter of crafting a new SAML profile that does stipulate one, and you will have what you're interested in. I nomially believe the DIX I-D could be recast as a SAMLv2 profile, fwiw. Hence, again, folks wanting to know why we need to specify something new protocol-wise, because that work's largely already been done. pbaker@xxxxxxxxxxxx said: > While I cannot claim any significant experience in the field of > 'identity' I think I can fairly claim to make a definitive > contribution with respect to the question of prior work as the > principle non-IETF works being cited all bear my name as editor. Only the SAMLv1.0 "core spec" does, and you share the editor billing with Eve Maler. You did not actively edit SAMLv1.1 nor SAMLV2.0, nor actively contribute to their development. It appears from mailing list archives that your active participation in the OASIS Security Services Technical Committee tapered off in summer/fall of 2002. SAMLv2 supersedes v1.x and is substantially different in various aspects, e.g. explicitly supporting the notion of identity federation, refined assertion schema, richer notions of protocol bindings and profiles, richer set of pofiles, etc. pbaker@xxxxxxxxxxxx later said: > The question of inbound credentials is not how to make the credentials > theft proof, plenty have solved that problem. The question is how to > use theft proof credentials in the existing Internet infrastructure. > How to make them snap into use. > This is not the problem that DIX is intended to solve but it is a > problem that DIX provides a solution for. Federate the authentication > scheme so that the identity holder chooses their own identity broker > and all things become clear and possible. this could be accomplished via a specific profile of SAML. > With DIX unified identifiers in place I can see how I could choose an > identity broker that supports a strong authentication scheme of my > choice (biometric, PKI, OTP) and use it with a range of sites without > each web site having to take special steps. the notion of a "global identifier" scheme is also being developed by various folks, notably the OASIS-based XRI (eXtensible resource identifiers) tech committee... http://www.oasis-open.org/committees/xri/ .. (which is on v2.0, and undergoing deployment) so any effort along those lines would also need to carefully evaluate/address prior related work, imv. JeffH _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf