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

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

Scott,

I take your point that in some situations two mechanisms that provide
essentially the same functionality may be required. But we have two
mechanisms already ! browser artifact and browser POST. Each has quite
different properties that may be suited to one situation or the other. 

If people don't like Javascript, they can use the browser artifact
technique. If people are concerned about referrals and URL logs they can use
FORM Post. We have also provided technology in SAML 2.0 to ensure that
assertions can be encrypted, so the browser POST contents can be hidden from
the eyes of the user agent (and their disk cache). 

So why do we need even more implementation choices for these solved
problems?

It would be really helpful if the end-users or vendors interested in any of
the additional variations stand up and identify themselves. I have no
objection to specifying optional implementation patterns. But I am deeply
concerned about making all of these mandatory to implement. It makes for a
very large and heavy specification that will be difficult to implement.

Speaking now as a representative of an ISV, I have to say that some of the
choices we seem to be making in SAML 2.0 (and, yes, even some choices made
in ID-FF 1.2) are going to be a large burden to implementers and act as a
brake on broad implementation. 

Every specification exists in the context of some business/social/economic
problem; there has to be a balance between the savings accrued by the
technology versus the cost of implementing the technology. IMHO, the
approach we are taking in SAML 2.0 may lead to a specification that receives
limited implementation because of the many different configurations that
need to be implemented and tested.

- prateek


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Monday, May 24, 2004 11:14 AM
To: Mishra, Prateek; security-services@lists.oasis-open.org
Subject: RE: [security-services] Dual implementations for each SSO binding?

> 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