Per-Entity Metadata Working Group

["Walter Forbes Hoehn (wassa)" <>]

> On Jul 27, 2016, at 2:33 PM, Cantor, Scott 
> <>
>  wrote:
> 
> On 7/27/16, 3:20 PM, 
> "
>  on behalf of Tom Scavo" 
> <
>  on behalf of 
> >
>  wrote:
> 
>> From where I sit, aggregate distribution and per-entity distribution
>> are like apples and oranges.
> 
> I do understand that one can tolerate outages that are an order of 
> magnitude larger, but in terms of fundamental requirements, they're both 
> potentially a highly redundant web presence serving static documents. 
> That's apples and some other more expensive kind of apples to me.
> 
> But I seem to be in the minority on this, so maybe we could focus this 
> discussion on your original subject line. What exactly do people need us to 
> implement? At minimum, on-disk cache, clearly.

The two things that came to my mind on the call were:

        - On-disk cacheing

        - Interval-based refresh, as opposed to simply expiring entries and 
having user interaction trigger a refresh

The idea would be 1) a client never loads metadata related to entities for 
which it has never sent/received a SAML request, and 2) for those entities 
that have been “seen” before, a client would behave much the same way it does 
today, exhibiting the same sort of robustness.

I don’t know that either of these features is a “need,” as I agree with your 
basic premise, at least as I understand it: i.e.: it’s more 
important/interoperable to implement resilience on the MDQ server end. 
Approaching the problem from BOTH the client and server ends, though, might 
have the benefit of substantially reducing the risks we’ve discussed for many 
sites.

-WFH