[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[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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]