Per-Entity Metadata Working Group

[Tom Scavo <>]

On Fri, Aug 26, 2016 at 10:09 AM, Nick Roy 
<>
 wrote:
> Thanks - does anyone think trying to distribute large aggregates with this
> service (alongside per-entity metadata) might be a problem?

First, a bit of history: In the beginning, all InCommon services were
served from virtual host wayf.incommonfederation.org. Remnants of that
still remain:

$ 
MD_LOCATION=http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
$ curl --silent --head $MD_LOCATION
HTTP/1.1 301 Moved Permanently
Date: Sat, 27 Aug 2016 13:56:10 GMT
Server: Apache
Location: http://md.incommon.org/InCommon/InCommon-metadata.xml
Connection: close
Content-Type: text/html; charset=iso-8859-1

When the community migrated to metadata signed using the SHA-256
digest algorithm, we took that opportunity to introduce two new
virtual hosts: md.incommon.org and ds.incommon.org. These became our
metadata distribution service and discovery service, respectively.

We did this for at least two reasons:

1) The discovery service requires TLS whereas the metadata service does not
2) The discovery service requires high availability whereas the
metadata service does not

We’re happy with the way that separation of concerns has turned out. No 
regrets.

Similarly, we’d like to introduce a completely new virtual host for
per-entity metadata distribution: mdq.incommon.org. Actually the
handwriting has been on the wall for some time since our beta MDQ
server, which has been running for two years, has hostname
mdq-beta.incommon.org, which is no coincidence.

The MDQ server (mdq.incommon.org) should serve per-entity metadata
only, no aggregates, for mostly the same reasons we subdivided
wayf.incommonfederation.org in the first place, including high
availability and TLS. (Yes, I support TLS on the MDQ server if we can
work out the details to everyone's satisfaction.)

One last point (for the record): Our current infrastructure for
distributing aggregate metadata (md.incommon.org) continues to work
well so there's no compelling reason to fix what is not broken. That
said, if we really want to migrate md.incommon.org to the cloud for
some reason, that's fine, as long as that remains a long-term goal at
the tail end of this overall effort. We don't want to be distracted
from our primary goal, which is to deploy per-entity metadata.

Tom