expirationWarningThreshold

Brent Putman putmanb at georgetown.edu
Mon May 22 13:40:41 EDT 2017



On 5/21/17 11:20 AM, Tom Scavo wrote:
> Okay, now I'm more confused. If the requireValidMetadata attribute is
> about *usage* of cached metadata, that's news to me.

Well, it's been there for over a decade, and this code hasn't
fundamentally changed in all that time.
 

>
> In any case, I edited the text for requireValidMetadata so that it
> corresponds to my understanding (which is probably wrong). Please
> review and edit as necessary.

The edits aren't correct.  The requireValidMetadata is not just about
the validUntil on the root element.  1) You're forgetting that more
than the root element can carry validUntil.  When processing a
candidate EntityDescriptor, that element's validUntil as well as all
ancestor element validUntils are checked.  2) Strictly speaking, in a
software sense, this is about descriptor element validity more
generally, as the original docs noted.  That could be about more than
validUntil checks (although currently that is all that is checked, as
was originally noted in the docs).  I'll revert the docs back, with a
little bit of rewording to make more clear.

FYI, in terms of symmetry, there is a similar config flag and logic on
the RoleDescriptorResolver impl.  Remember that RoleDescriptor can
carry validUntil as well.


> If we were starting from scratch, would it make sense to expose the
> latter two configurations only? AFAICT, the first one isn't really an
> option. I claim an implementation doesn't have the option of ignoring
> the validUntil attribute. Do you agree?

Like Scott, I disagree.  Aside from other low-level software use cases
where you might really want to process "invalid" metadata, there's also
the case of a broken metadata source that's taking awhile to get
fixed.  If you're an IdP and you have to tell your users that they
absolutely can't use some service because of some stale/expired
metadata, due to hardcoded and un-changeable software behaviour, then
that might be bad.  This flag puts that decision into the hands of the
IdP deployer.  If they are OK with temporarily disabling that check
while the situation with the metadata source gets sorted out, then that
ought to be their decision.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170522/8cff2e24/attachment.html>


More information about the dev mailing list