Dual implementations for each SSO binding?

["Mishra, Prateek" <pmishra@netegrity.com>]

All of the discussion below references sstc-saml-bindings-2[1].0-draft-11.sxw

 

1)

[begin-text-quote]

3.4 HTTP Re-direct/POST binding

lines 451-456

 

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.

[end-text-quote]

 

 

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.

 

2)

[begin-quote]

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.

[end-quote]

 

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

use-cases?

 

 

3)

 

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.