<html>

<head>

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

</head>

<body>

<blockquote type="cite">

<div>Based on the domain from your email address I looked at the InCommon</div>

<div>copy of your IDP's metdata (entityID urn:mace:incommon:jmu.edu) and</div>

<div>that has no sign of SAML2.0.</div>

<div>So I still think Scott is right and you're up for a long and hard</div>

<div>transition period.</div>

</blockquote>

<div><br>

</div>

<div>Hmm, it would seem the metadata we have on the IDP and the metadata InCommon publishes aren't as in-sync as I suspected.</div>

<div><br>

</div>

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

<div><br>

</div>

<div>Brandon</div>

<div><br>

</div>

<div>On Wed, 2015-07-22 at 17:17 +0200, Peter Schober wrote:</div>

<blockquote type="cite">

<pre>* McKean, Brandon Scott - mckeanbs <<a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> [2015-07-22 16:49]:

<blockquote type="cite">

<blockquote type="cite">

I assumed the OP already had SAML2 support in metadata and was merely

considering removing SAML1 wholesale. Seems that's not the case (no

sign of SAML2 for JMU, in 2015), so I misunderstood the much wider

implications of that question than removing potentially unneeded

SAML1 endpoints.

</blockquote>

Hmm, perhaps I don't fully understand the implications of the metadata

myself. What I previously emailed was the current metadata, with the

SAML2 elements there.

</blockquote>

Based on the domain from your email address I looked at the InCommon

copy of your IDP's metdata (entityID urn:mace:incommon:jmu.edu) and

that has no sign of SAML2.0.

So I still think Scott is right and you're up for a long and hard

transition period.

-peter

</pre>

</blockquote>

</body>

</html>