session not sticky or something else?

[Peter Schober]

* Michael A Grady <mgrady at unicon.net> [2013-01-07 17:39]:
> But if you only have a few SPs that are still using a SP 1.x/SAML
> 1.1 version of the SP, the easiest thing from your perspective would
> be to get those services to upgrade to a Shib 2.x SP and push
> attributes. And that would put them on actual supported code.

The most common case we had was resource providers already running
Shib 2.x (so being fully capable of SAML2 and encrypted assertions)
but forcing use of SAML1 via home-grown code initiating sessions.

So the SAML (often Shibboleth) implementation would be able to recieve
encrypted assertions (as I could verify myself, using my IdP and their
Shib handler endpoints) if only the custom code initiating sessions
would go away and let the SP select the right protocol.

That proved to be much harder than simply telling them to upgrade, as
it involves custom coding on the SP side (if only to remove stuff) and
also sometimes lots of questions about protocol implementation, spec
exegesis and fingerpointing. And then waiting for things to eventually
move from dev to test to QA to production, which, for the average
publisher could mean years.
-peter