Simple SAML

[Cantor, Scott]

> I agree that I don't think they're using SAML 2.  What I keep getting into is
> they're constantly pointing fingers at my testshib server saying it's on our side.
> They did it again today.  I have other SPs that use this just fine and am having
> no problems when I use sp.testshib.org <http://sp.testshib.org> .

Which of course is not a technical problem, or one solved by documentation. When people have a goal of "not doing something", no amount of evidence can move them off that goal since it's a default state and they are in the state they wish to be in.
 
If the issue is that you're supporting SAML 1.1 now and the SP is in use with it, and you would like to turn it off, that's a tough problem. I'm in that state and yes, I have several SPs from an organization that simply isn't going to move, so unfortunately I'm stuck. But no amount of understanding the tech gets me unstuck. It's a people problem.

If you're not already "live", the best option, if you wish to not support SAML 1.1, is not to support it. Then you have an interop issue and if the service is valuable enough to some customer of theirs, presumably they'll be forced to deal with their error.

Incidentally, don't forget discovery as a cause. It's not prevalent anymore, but the old WAYF protocol dating back to Shibboleth 1.x is a SAML 1.1 flow. That's the most common source of SPs stuck doing SAML 1.1 while having metadata for both versions in place.

-- Scott