expirationWarningThreshold

[Cantor, Scott]

> 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.

The use case for me is my local metadata feeds that my customer(s) keep breaking on me and then complain when my system just consumes their expired metadata. The warning gives me a clearer signal they broke it and some advance notice if they do.

In the current code, you get *no* indication anything is up until it expires and then you just get errors of the "no metadata found" sort, which make you think it's just people using the wrong entityID or something.

> 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.

Yes, s/federation operator/metadata source

There's no default value with any meaning, the value is dependent on the metadata source and what you're going to do if it barks. It isn't deriveable from any other setting directly, though it's obviously related to the validity period.

-- Scott