Page History

Phase 1 Implementation Plan: Frequently Asked Questions

In September 2013, the Metadata Distribution Working Group submitted its Phase 1 Phase 1 Recommendations to the InCommon Technical Advisory Committee. This FAQ anticipates questions and concerns regarding a Phase 1 Phase 1 Implementation Plan to be initiated December 2013.

...

Yes, for the first time since the formation of the InCommon Federation, the location of InCommon metadata is changing. This is a big deal, we know. If we could avoid it, we would, but the time is ripe for change.

InCommon Operations will deploy three new metadata aggregates at the following permanent HTTP locations:

...

Multiple, heterogeneous services currently run on legacy vhost wayf.incommonfederation.org, namely, InCommon Metadata Services and the Discovery Service. To provide better quality of service, these services need to be segregated onto their own separate vhosts (md.incommon.org and ds.incommon.org, resp.). Note: The InCommon Federated Error Handling Service is already running on ds.incommon.org.

If this were the only reason to move to a new vhost, we probably wouldn't be doing it (which is why we haven't done it until now). There are other, more significant reasons for making this change. See the Phase 1 Phase 1 Implementation Plan for a complete list of drivers, some of which are discussed below.

Is the current HTTP location of InCommon metadata going away?

What will happen to the legacy vhost?

Yes. All metadata services on legacy vhost wayf.incommonfederation.org will be decommissioned on March 29, 2014. At that time, we will install a redirect from the legacy metadata aggregate to the new fallback metadata aggregate. That redirect will remain in place indefinitely.

...

Moving forward, all new metadata aggregates will be signed using a new self-signed signing certificate set to expire on December 18, 2037. We In the future, we don't intend to re-sign the new self-signed metadata signing certificate unless it's absolutely necessary.

...

What does SHA-2 have to do with metadata?

XML signature Signature uses a so-called digest algorithm to compute a hash of the signed XML node. The current metadata signing process relies on the SHA-1 digest algorithm. We are updating the process to use SHA-2 instead of SHA-1.

Two Out of the chute, two of the new metadata aggregates will use different digest algorithms while (the third aggregate is for future use):

• The new production metadata aggregate will be signed using a SHA-2 digest algorithm (specifically, SHA-256).
• The new fallback metadata aggregate will be signed using the SHA-1 digest algorithm (which is what we use now).
• The new preview metadata aggregate will be aliased identical to the production metadata aggregate.

...

The fallback metadata aggregate is transient in the sense that backward compatibility is provided for a limited, predetermined period of time. In the case of SHA-2, deployments have approximately three months (beyond the March 29 milestone) to become compatible with SHA-2. At that time, the fallback metadata aggregate will be synced with the production metadata aggregate, which forces all deployments to conform.

...

...