Per-Entity Metadata Working Group

[Chris Phillips <>]

What comes through to me in the conversation around 'transport' of the MDQ
records is that it's about the SIGNATURE on the record to indicate
trustworthiness NOT the transport.

While we've always said this often to the comments like: 'hey why are you
not using HTTPS for this? Isn't it insecure?

Now, grain of salt time..

If it was ONLY about validation then anything could carry it.  But I
contend it's not. We need health and operational instrumentation for
diagnosis and options for predictive failure monitoring.

It's often important to have the operational capability to pinpoint 'Hey,
you fetched X at time Y and then never again -- of course it doesn't
work!' 
OR
'Hey, our [strong] recommendation is to retrieve aggregate hourly -- why
is X % of our federation showing a retrieval rate of daily or weekly?!?'

You can only triangulate things like this if:
- you host the content somehow and have access to logs
- have access to retrieval traffic
- have some mechanism to signal the mothership about current IDP/SP state
or evidence in logs that this was the culprit.

This is/was the rationale behind samlbits.org being able to send syslog of
retrievals for a given domain -- you can actually see the CDN in action on
YOUR aggregate.  This at leasts gives you on par stats if it were served
up from your own apache web server.


Delivering federation trust via MDQ will be easier to support if there are
ways to instrument its use and ability to diagnose.
Otherwise adoption will stumble on 'Hey, I tried MDQ and didn't work and I
couldn't tell why, I'm switching back to aggregates'.

I would suggest that these are risks and needed expectations to call out
in the report.  If someone (institution or fed) chooses to use dropbox,
great, but go in eyes open of what you are trading off.
Even the largest services brownout from time to time and realize that too
is the reality that one could be open to. If AWS region X goes down, so
does your federation?  Is that an acceptable risk?
 Maybe, but explain that to the CIO who gets hammered because students
can't sign in to write exams and they have to reschedule thousands of
people's lives in the absence of the ability to sign in.

C





On 2016-08-04, 9:53 AM, 
"
 on behalf of
Cantor, Scott" 
<
 on behalf of
>
 wrote:

>> Open this directory structure for access via rsync, Dropbox, OwnCloud,
>> 'you name it' to sync the signed files to campuses operating their own
>> local MDQ server to get independent from the centrally operated MDQ. No
>> need for HTTP proxies, just for local MDQ servers at the campuses.
>
>Right, but how many campuses will want to do that? How many will bother?
>How many will ignore the whole issue because they're being told that
>moving to this new approach suddenly requires extra work from them?
>
>The group consenus was that while nothing we do should or will make that
>approach difficult for people to implement, we shouldn't focus on it as a
>workaround for delivering a reliable service.
>
>All that said, the Dropbox idea is a good one. Why not piggyback on
>existing cloud services? I like it.
>
>-- Scott
>