Per-Entity Metadata Working Group

["Cantor, Scott" <>]

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. But again, you can make the same argument about DNS, and AFAIK systems 
don't generally cache DNS lookups on disk. And when it breaks, yeah, 
everything just goes belly up.

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.

I heard the points being made about the system now tolerating short outages, 
but I don't think the best solution is going to be to make every client 
tolerate that.

If we really, really don't think we can do this, then I think we need to 
shift more radically toward metadata at the endpoints. That's never been 
something I object to, though I do object to self-asserting it. But that was 
something that a lot of us spent time thinking about, and at the time, the 
conclusion was "that's just not practical for most deployers, they don't want 
to bother with it". Maybe that's changed, but I wouldn't say there's any 
actual evidence either way.

-- Scott