I have some comments on draft-merrells-dix-02. I'll touch on only the
first-order ones in this message -- there are various detail-level issues I've
noticed, but I'd rather discuss the former first.
Although it is good (for various reasons) that this spec has been recast
nominally in the form of a "SAML profile", I don't feel it is, as presently
written, actually one.
Rather, the spec is written more in terms of attempting to wedge a slight
veneer of SAML into the SXIP framework. For example, retaining the "DIX
protocol" terminology, as is done in section 3, and in the entitling of section
4.3 as "Employing SAML in DIX", is symptomatic.
Specifically, rather than appropriately reusing the SAML Authentication Request
Protocol and the SAML Assertion Query and Request Protocol,
draft-merrells-dix-02 invents its own Fetch protocols and messages (which are
analogous to the former SAML abstract protocols), only cursorily basing them
upon the SAML RequestAbstractType. These protocols do not reuse the notion of,
and elements for, "Subject"s -- rather, inventing their own top-level elements
for naming of entities (eg "SPName").
Since SAML presently doesn't have a notion of a "store" protocol, it is
reasonable to invent such, though I believe one could design it such that it
intersects more fully with SAML approaches.
Furthermore, the notion of SAML assertions as a means of concisely conveying
Subject information is not directly employed. SAML assertions are nominally
profiled in draft-merrells-dix-assertion-00, but, for example, are not actually
employed in draft-merrells-dix-02.
The reasons these points matter are at least..
* established SAML semantics largely aren't employed - thus all the added-value
security knowledge-base that they represent is not leveraged
* crafting implementations facilitating convenient re-configuration to
"turn security on" isn't facilitated (i.e. security mechs other than those
sxip-derived ones that are in the spec)
* ditto for facilitating "turning on identity federation"
This is a serious "lose", in my view.
As such, although they are a "SAML profile" in some small, nominal fashion,
these specs are _not_ in my view crafted in the terms of the present family of
SAML profiles, and thus will tend to foster divergence rather than convergence.
I suspect it is possible to craft a lightweight SAML web SSO profile that can
support the sxip features (eg the signing approach) desired by some, and also
support other, more conventional signing approaches (but not use xmldsig) --
both of which can be optional so it can be deployed in ultimate lightweight
fashion if desired. This profile, designed with established SAML semantics and
approaches, will then facilitate deployments' migration (perhaps even by
reconfiguration) to more robust security and identity federation if desired.
JeffH
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
