Clarification of failFastInitialization Metadata Option

[Peter Schober]

* Tom Scavo <trscavo at gmail.com> [2016-03-10 16:33]:
> On Thu, Mar 10, 2016 at 9:54 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> > Sure, but it's also avoided if the metadata is curated locally,
> > and most often if the vendor won't join, that's your second
> > option.
> 
> I strongly agree with that, and that should be the primary take-away
> from this thread.

Indeed. Besides avoiding the gaping hole of an SP feeding arbitrary
crap into your running IDP, that also means you can perform all kinds
of checks on locally available metadata before loading it into your
IDP (cf. MetadatCorrectness in the wiki).

Looking at the problem this way you could throw additional tooling at
the issue, e.g. running in instance of the MDA or http://pyff.io to
aggregate the metadata into local files, performing additional checks
etc. and only then loading it into the IDP.
But that doesn't change the much more funcamental point Scott made
(again quoted below) that pulling metatdata from SPs directly is just
an anti-pattern. For trust reasons as well as for
operational/resilience reasons:

> > There really is no scenario in which a vendor actually has
> > metadata, won't join a federation, and could be trusted to
> > maintain the metadata accurately for remote access while honoring
> > the actual purpose of having the metadata refreshed. They'd botch
> > it somehow, be it the way this one did, or by screwing up the key
> > rotation or endpoint changes if they made them by not separating
> > the metadata from the actual change to the system itself, etc.

-peter