Deployers have multiple metadata aggregates from which to choose. This page outlines available options. Policy considerations and general configuration issues are discussed on the Metadata Consumption page. Guidance on how to configure specific Metadata Client Software is available elsewhere in this wiki.
InCommon DOES NOT serve metadata via TLS (HTTPS). This is intentional, as it discourages deployers from incorrectly trusting transport security, when document-level security is required. TLS does not provide sufficient protection against metadata tampering. InCommon and other Research and Education federations require customers to verify the XML Digital Signature at the root of metadata documents, using a public key configured for explicit trust. Federating software that cannot:
Is not compatible with scalable multilateral SAML federation, and SHOULD NOT BE USED with InCommon or other federations.
All aggregates listed below are production-quality metadata aggregates.
As of January 31, 2018, you may also use TLS ( to download the aggregates noted above. You are strongly advised not to depend solely on TLS for the security of your metadata downloads, and to continue the critical practice of verifying the signature on metadata according to the instructions on the Metadata Consumption page.
All metadata aggregates are signed using the same metadata signing key and the SHA-256 digest algorithm. To verify the signature on an aggregate, a consumer must obtain an authentic copy of the InCommon Metadata Signing Certificate.
|Advanced Tables - Table Plus|
The Fallback Aggregate is transient in the sense that backward compatibility is provided for a limited, predetermined period of time. This forces deployments to adjust to breaking changes to metadata albeit in a controlled environment.