Behalf Of Jeff(_dot_)Hodges(_at_)KingsMountain(_dot_)com
The original claim made by Dave Crocker was that this is an area that is
essentially not understood by anyone. I disagree, I think that it is an
area that is very well understood and one in which many of the problems
have already been solved.
If someone attacks my professional competence in a public forum I
believe that I have the right of rebuttal. It is difficult to see how
such a claim can be effectively rebutted without pointing to work done
in that field.
As I pointed out in another message the 'we do not understand this'
trope is essentially a rhetorical trap where the target has to either
admit they don't understand the problem or appear to be immodest. Having
heard it used in MARID and DKIM I decided to draw the line more firmly
this time.
I note that while we disagree on the need for a new protocol here you
are essentially doing so by arguing that the problem is already solved
which is an even stronger rebuttal of the claim that the problem is not
understood.
I disagree. SXIP (nee DIX) is overall attempting to solve
essentially the same problem space that the SAML web browser
SSO profile addresses.
There is some overlap between the use cases but not between the
deployment communities.
I have already suggested that people in DIX look at the SAML artifact
and look at how that might solve the same problem.
There may be more convergence possible, I think that this is best done
through face to face meetings.
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??".
However having talked to several of the DIX people and looking at the
environment where they propose to deploy I think that there is a case to
be made for an ultra-minimal protocol.
My concern here is that there may be a parallel with X.509/PKIX which
solve every imaginable security problem but we still find that there is
a utility to lightweight hacks like SSH.
I don't want to wait five years to find out that we need a lightweight
hack in addition to SAML.
If we had handled things a little differently when the need for the SSH
approach had first been spotted we might have come up with a hybrid
scheme that provides a seamless transition from lightweight SSH keying
to full PKI.
My principle concern these days is design for deployability. SAML was
designed with a particular deployment stragegy in mind and it is being
relatively successful in its early adopter niche. Liberty has a more
ambitious goal which again begins from an early adopter niche. The
Identity 2.0 community is working from a totally separate niche, one
that did not exist in 2000 and one that has the potential to be by far
the most rapid.
Done right these three strategies might all meet in the middle.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf