A User Story about an InCommon Sponsored Partner

This is a true story about the trials and tribulations of a Sponsored Partner in the InCommon Federation (who will remain nameless).

• Vendor V is an InCommon Sponsored Partner in good standing.
• Some of V’s partner IdPs are InCommon participants and some are not.
• On Dec 5, 2013, V introduced a new certificate into SP metadata since the existing certificate was set to expire on Dec 15, 2013.
• V is following the SP certificate migration strategy documented in the wiki, that is, only one encryption certificate will be in metadata at any given time (which is a requirement of AD FS, btw).
• On Dec 16, 2013, V reported that three non-InCommon IdP partner deployments stopped working.
• The three deployments that failed are running AD FS. V itself is running simpleSAMLphp (SSP).
• Given what we know about AD FS, we can conclude that the three AD FS IdPs failed because there was an expired certificate in V’s metadata.
• Besides InCommon, V has IdP partners in two regional federations: the NC Federation and the Texas Federation.
• Some of V’s IdP partners (such as the three AD FS IdPs mentioned above) belong to no federation.

Problem: How does V share metadata with all of its partners so as to eliminate potential interoperability issues?