Estimated reading time: 3 minutes
August 18, 2020
By: Nic Roy, Internet2 Trust and Identity Services
It’s been over a year since InCommon’s new production metadata service went live, and I’m pleased to say that it has an operational record of 100% availability over that entire period. As of this writing, it’s had 100% uptime for over 400 days.
This new service supports a feature known as MDQ (metadata query), also known as per-entity metadata delivery. Rather than downloading the entire ever-growing metadata file, your software retrieves only the information it needs at the time it needs it. This is a more efficient way of querying and delivering metadata and is the long-term supported solution for interoperability. The service also still supports the legacy metadata aggregates, albeit with a new metadata signing key.
At some point in the next few months, InCommon will work with its community governance bodies (specifically, the InCommon Technical Advisory Committee or “TAC”) to determine a sunset date for our old metadata service which lives at md.incommon.org. The new service is at mdq.incommon.org.
Participants should prepare to move their software to the new metadata service, and to update the key that they use to verify that their copy of metadata has not been tampered with, to the new metadata signing key. More information is available in our documentation of the new service.
You may have some questions about this. Here are a few that we’ve thought of and some quick answers:
- Question: Why is InCommon moving the URL for the metadata service, thus necessitating a change to my federating software configuration?
Answer: We are changing the signing key for the federation metadata (see the next question) and we wanted to clearly delineate and de-conflict which signing key is used to sign which set of metadata. Thus, a change in the URL is an easy way for both us and you to tell that you’ve moved away from the old service, which will eventually go away.
- Question: Why is InCommon changing the metadata signing key?
Answer: The old signing key has been in use for over 15 years, and is only 2048 bits in size. It was time to use a new, larger key (3072 bits) that was freshly minted and had never been used as part of the old manual signing process. This allowed us to create a clean risk profile for the new service.
- Question: How long do I have to move to the new service?
Answer: That’s not yet set in stone, but we foresee a migration period of approximately one year after we work with the TAC to set a date to start communicating directly with InCommon Site Administrators and Execs about the change. It’s better for you to use the new service for all new deployments, starting now. In order to reduce confusion about which metadata you should be using, we have removed information about the old metadata service from our documentation library. All existing software that uses InCommon metadata should be changed to the new metadata service (using either the metadata query “MDQ” protocol, or the legacy aggregates, most of which are still supported in the new location) as soon as possible. See documentation linked above for more information on how to do this. Where possible, deployers should use the much more efficient MDQ protocol- it will save you massive amounts of memory and CPU time, not to mention reduce network utilization.
Other questions can be sent to us at help@incommon.org and we’ll work to get you answers in a timely manner.