RE: [security-services] Dual implementations for each SSO binding?

[Scott Cantor <cantor.2@osu.edu>]

> 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.

They are not the same end result, but address messages and clients with
different properties of size and behavior to optimize the user experience.

Specifically, I know lots of people don't like POST, because of the
requirement to use JavaScript to avoid the extra click, which some clients
don't support. So they want a GET-based mechanism. But some messages, in
particular the Response+signed Assertion, can't fit in the URL.

IMHO, it's *easier* to not deal with these distinctions by looking at
messages and deciding case by case. It's easier to simply layer the code so
that messages can be built without regard for the binding and then shipped
over whatever general encoding and binding is defined, and the spec reflects
this.

> 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?

This was something ID-FF defined, but I don't know the reasoning in this
particular case (unlike above, which I have my own reasons for favoring). I
believe it had to do with mobile client requirements (but then I usually say
that when I don't know).

I will say that one advantage of POST is that the artifact doesn't get
logged over half of creation because it's in the URL, in the referrer
header, etc. That referrer problem is a serious one, as the IBM paper noted,
and something we have to look at before we're done.

> 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. 

I think it's harder to get right if I have to write all kinds of conditional
code for sending particular messages in particular ways, personally. Liberty
was a lot less explicit about the fact that the various flows had to support
both GET and POST, and that led to interop problems, based on what I was
hearing, so I wanted to address that explicitly, one way or the other.

> 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.

I don't *personally* have a strong need for GET at all, but that's because
my target market is almost exclusively desktop browsers that handle POST and
JavaScript just fine. But I know others do.

-- Scott