Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] Metadata changes on

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] Metadata changes on

Chronological Thread 
  • From: Tom Scavo <>
  • To: "" <>
  • Cc: Tom Scavo <>
  • Subject: Re: [Metadata-Support] Metadata changes on
  • Date: Fri, 19 Feb 2016 19:35:43 -0500

On Thu, Feb 18, 2016 at 12:58 PM, Tom Scavo
> On Thu, Feb 18, 2016 at 12:41 PM, Kevin Foote
> <>
> wrote:
>>> On Feb 18, 2016, at 9:30 AM, Liam Hoekenga
>>> <>
>>> wrote:
>>> I asked a question on the shib user's list that Tom thought would be more
>>> appropriately discussed here.
>>> Is there a long term goal to migrate the metadata published by InCommon
>>> to MDQ instead of using a static metadata aggregate?
>> Or even offer for some interim period both methods for consumption.
> I think it's fair to say that the jury is out regarding both
> questions. In fact, I'd like to turn it around and ask the community
> for its input. Community input has a significant effect on the
> InCommon governance process.

Hearing none, I'll offer my opinions (which are just my opinions since
InCommon has no official stance on the matter). Take it with a grain
of salt.

InCommon is the second largest federation in the world (after the UK
federation) but AFAIK the InCommon metadata aggregate is THE largest
aggregate in the world. How is that possible? Well, the UK federation
aggressively exports a large portion of its metadata (both IdPs and
SPs) while InCommon has a relaxed opt-in policy for exported SP
metadata. Moreover, InCommon has more SP metadata than all other
federations combined! Taken together, these facts explain why the
InCommon metadata aggregate tops the charts at ~32MB in size.

The Shibboleth software handles metadata very well, which is basically
why the sky has yet to fall. While some deployers are feeling the
pain, most are hanging in there. It's just a matter of time, however.

With the introduction of eduGAIN metadata, we may have just missed a
Golden Window of Opportunity. If we had a production MDQ server, some
deployers would have gladly migrated to it given the problems we're
seeing with the aggregate. Shibboleth IdP V2 deployers don't have that
option, however. So maybe the Window wasn't quite so Golden after all.

In any case, I personally believe we need a production MDQ server
sooner, rather than later. We think we know how to build one of these
things, but I'm not sure we have the resources to pull it off. So MDQ
will have to wait for the stars to align (or the gravitational waves
to superimpose :)


Archive powered by MHonArc 2.6.16.

Top of Page