Per-Entity Metadata Working Group

[Thomas Lenggenhager <>]

I'm only now catching up with this thread from last week.

Having read the proposals for HTTP proxies and their issues I wondered 
whether the following approach would not be more appropriate.

The federation operates a hidden master that signs the files and pushes 
them to the publicly accessible centrally operated MDQ servers. All 
signed entities are placed in some directory structure.

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.

Primary drawback is that you introduce a new dependency on the file 
syncing infrastructure. With the multi-day validity of the signed files 
that should not be a real issue if you pick a technology that is anyhow 
widely used and looked after.

Thomas

On 27.07.16 22:46, Nick Roy wrote:
> If we design the service to be highly available, I don't think we need to 
> worry about on-disk cache, which as Scott has mentioned is at the expense of 
> the ability of other non-Shibboleth clients to support the same assumed 
> requirement.  I think we should focus on a highly available per-entity 
> metadata delivery architecture with the assumption that many clients will 
> never have the ability to support the on-disk caching.
>
> That said, if others want to run their own local copy, why don't they just 
> stand up local HTTP proxies?  This isn't that difficult for them, but I think 
> that part of the equation is out of scope for this group.
>
> Nick

--
SWITCH
------
Thomas Lenggenhager, Central Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 1505  direct +41 44 268 1541
https://www.switch.ch