expirationWarningThreshold

[Tom Scavo]

I now understand how the expirationWarningThreshold works (thanks
Brent). I'm still not clear on the intended use case, however, so let
me iterate one more time.

On Sun, May 14, 2017 at 7:30 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> On 5/14/17 7:15 PM, Tom Scavo wrote:
>>
>> For the current operation, expirationWarningThreshold might be set to
>> PT7D (or more). For the future operation, PT3D makes sense.
>
> Well, I personally think both of those are way too long.  I think probably
> 24 hours is the most that makes sense - unless you really don't want to get
> notified and have to do something on a weekend, in which case maybe it's
> longer. (But I don't see how IT devops people can really get away with that
> these days...)   But each person will have their own requirements.  It's
> really more of an operational question of how paranoid you want to be.

At this point, I'm not entirely sure what advice to give if this comes
up on the users list, but there's one thing I'm sure about: a metadata
provider configured to refresh federation metadata with
expirationWarningThreshold="PT24H" won't do anybody much good since a
deployer doesn't directly control the validUntil attribute on
federation metadata. Once a warning is issued, the metadata will
certainly be rejected by the software in 24 hrs unless the federation
operator intervenes. So it seems to me a deployer will want to know
well enough ahead of time (or not at all) so that the federation
operator can be alerted.

Am I missing something?

Tom