Per-Entity Metadata Working Group

[Tom Scavo <>]

On Wed, Jul 27, 2016 at 12:27 PM, Cantor, Scott 
<>
 wrote:
> On 7/27/16, 12:01 PM, 
> "
>  on behalf of Tom Scavo" 
> <
>  on behalf of 
> >
>  wrote:
>
>>    Does it make sense to maintain "backing files" of per-entity metadata?
>>    That is, each resolved entity descriptor is cached in a local
>>    directory, and at startup, the cache is used to initialize the
>>    deployment. (As an aside, this can be implemented using the new
>>    "file://" feature in Shibboleth.)
>
> Walter and others brought that up on the call. Sure, lots of things could 
> be done...
>
> I'm not saying these things aren't worth doing, but when you consider the 
> huge lag in both development cycle and upgrades, and the fact that nobody 
> else is going to spend the effort to do this, it just really isn't IMHO the 
> best way to look at the problem from the federation end.

Yes, that's a good point but: Shibboleth is easily the best
implementation of a metadata client on the planet. It's no coincidence
such a large proportion of deployers use it. We wouldn't have been
able to get all those deployers to invest in Shibboleth if there were
no backing file feature. Dead-in-the-water at startup is not an option
for many production deployments.

We can deploy an MDQ server with the installed client base that we
have as long as we manage expectations. There are many deployments
that CAN tolerate dead-in-the-water at startup. As long as we clearly
communicate what CAN happen and what we've done to mitigate the
possibility, I think that's fine.

Tom