<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head>

<body>

<blockquote type="cite">

<div>It will break any SP that is not properly configured to immediately support, migrate to, and seamlessly adapt to, use of SAML 2.</div>

<div><br>

</div>

<div>That set could be empty, a few, a dozen, or a lot. Probably "a few".</div>

</blockquote>

<div><br>

</div>

<div>Ah, I see why that process has been pushed back so much then.</div>

<div><br>

</div>

<div>Maybe I simply don't understand, but why would there be any breakage at all if SAML1 support is still listed in metadata alongside SAML2 support? Does it go back to SP side implementation issues? I suspected SP software would just use what it could from

 that and things would go smoothly, but I also may be giving it too much credit.</div>

<div><br>

</div>

<div>Brandon</div>

<div><br>

</div>

<div>On Wed, 2015-07-22 at 15:39 +0000, Cantor, Scott wrote:</div>

<blockquote type="cite">

<pre>On 7/22/15, 11:27 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> wrote:

<blockquote type="cite">

In that case, I suspect the next step would be to publish the current metadata to InCommon. That is, the one with both SAML1 and SAML2 support. That shouldn't break anything provided I

include support for all protocols that are currently listed, right?

</blockquote>

It will break any SP that is not properly configured to immediately support, migrate to, and seamlessly adapt to, use of SAML 2.

That set could be empty, a few, a dozen, or a lot. Probably "a few".

-- Scott

</pre>

</blockquote>

</body>

</html>