Per-Entity Metadata Working Group

[Tom Mitchell <>]

From a marketing standpoint, if you will, using phrases like “significant work” will kill MDQ. Even a hint that InCommon IdPs and SPs should consider standing up their own cache/proxy/container/vm to participate in MDQ will also doom the initiative.

I agree with Scott C. that the effort to either add an MDQ metadata source, or switch from an aggregate to MDQ, even if the signing key is different, is a small change. Some operators may view it as onerous, but when you get right down to it, it’s a config file change. If and when the time comes to advertise the MDQ service to members, InCommon should present instructions for various software platforms (Shibboleth, SSP, etc.) just as it has successfully done for other such efforts.

And I agree with Nick that the road to MDQ container adoption at campuses is an uphill battle. Taking a slightly different tack, would it be possible to do a little math to figure out order of magnitude load for an MDQ system? Given some number of sign ons per day, and assuming some reasonable cache lifetime in memory, with no restarts, perhaps we could figure out how many hits per hour/minute/second an MDQ infrastructure would need to handle to fulfill the needs of InCommon’s 434 identity providers and 3,107 service providers. I am not well versed in higher ed single sign on, so I couldn’t even guess at numbers for IdPs, and my SP is relatively small, so my numbers are likely tiny in comparison.

Thanks,

Tom

On Aug 4, 2016, at 4:46 PM, Nick Roy <> wrote:

Tweaking a relying party config is an order of magnitude simpler than standing up a pre-pacakged VM.  Most systems admins worth their salt won't allow a black box like that if it's critical infrastructure, and many wouldn't have the resources to make it highly available.  Absent that, it becomes a liability, not an asset in terms of high availability.

Nick

On Aug 4, 2016, at 2:30 PM, David Walker <> wrote:

Agreed that it's really just a couple of minutes.  My point was that any change is viewed as "significant" to many system administrators.  The thing going for us is that, ultimately, doing nothing is not an option.

David

On 08/04/2016 01:19 PM, Cantor, Scott wrote:

*	IdP and SP administrators will need to do something to take
advantage of per-entity metadata distribution.  Even assuming we don't ask
them (or their institutions) to run the distribution layer, they still have
significant work to do.

I would not agree that a few config changes is significant work. Getting people to do it is a hassle, but that's not because it's hard, it takes a couple of minutes to do the change. If you're thinking in terms of some kind of large scale testing activity by every site, we can't go into this with that expectation.

The most significant work would be if we change the signing key, but that's work "in theory" since in practice people don't carefully validate trust anchors just because they should.

*	If we did ask them to run their part of the distribution layer, we could
provide them with an instrumented VM container.

Still a non-starter IMHO. What you'd have to do is force us to built it into the software, essentially.

-- Scott