Per-Entity Metadata Working Group

["Cantor, Scott" <>]

> *     Setting an expectation that MDQ client software should protect itself
> from failures of the server infrastructure.  We've talked a good amount
> about the pros and cons of this.

It's not so much the idea that there's a "con" to it, it's that there's a 
point of diminishing returns and of the difficulity in getting things like 
that implemented more widely. From a service delivery standpoint, I still 
think DNS is the right expectation, but it's true that one of the reasons 
that got moved into a lot of OS kernels was to improve caching.

> *     Another risk to per-entity metadata distribution we haven't
> discussed, that the server infrastructure may not be able to handle peak
> loads.

I think if it's not signing, it's expecting very little to assume pretty much 
any reliable web environment couldn't handle the load we're talking about 
here.

> The next thing I realized is that the UK's approach of creating an 
> Apache-like
> web server layer between the MDQ server and the client IdPs and SPs
> doesn't require that the web servers be run by the federation.  They can be
> run by the member institutions:

Yes, they can, but they shouldn't *have* to. If you're expecting every 
deployer to have to run a proxy, you're asking too much of people IMHO. So 
I'm open to the argument that the client's going to have to cover for us for 
X amount of time, it's just that we don't have shipping code doing that.
 
-- Scott