[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Dual implementations for each SSO binding?
All of the discussion below references sstc-saml-bindings-2.0-draft-11.sxw
3.4 HTTP Re-direct/POST binding
There are two general ways to encode messages for use with this binding. One is to encode the message into URL parameters and the other is to encode the XML instance in base-64 and then place the result in an HTML form control. When URL encoding is used, the HTTP GET method is used to deliver the message, while POST is used with form encoding.
All endpoints that support this binding MUST support form
encoding and at least one URL encoding technique.
Why is it necessary to mandate support two distinct techniques for
achieving a single end-result? The use of MUST at this level is particularly troubling to me.
Lines 632-635 state
HTTP artifact Binding
There are two methods of encoding an artifact for use with this binding.
One is to encode the artifact into a URL parameter and the other is to place
the artifact in an HTML form control. When URL encoding is used, the HTTP GET
method is used to deliver the message, while POST is used with form encoding.
All endpoints that support this binding MUST support both techniques.
As in 1) above, why is it necessary to mandate use of two distinct techniques
to deliver artifacts? Why isn't the URL technique adequate for the intended
Overall, my concern is with the combinatorial explosion of testing and implementation. The larger this burden, the less likely it is that vendors will get it right and smaller the number of conformant implementations.
In SAML 1.1 we had two different profiles for SSO: artifact and FORM Post. This is already something of a burden, but there is clear rationale for each of these choices (push vs. pull, front-channel vs. back-channel).
In SAML 2.0 we are now further proposing that each of the profiles themselves have two technical variants (as explained above) AND that both variants must be implemented.
I am unable to see the justification for this generality. I would prefer bindings that describe all the different ways that SAML assertions may be transferred from one site to another, but that profiles and/or the conformance document pick out a few specific ways that must be supported in implementation.