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(_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.
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(_at_)verisign(_dot_)com 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(_at_)verisign(_dot_)com 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf