metadata early warning system

[Tom Scavo]

On Thu, Apr 5, 2018 at 10:27 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 4/5/18, 10:13 AM, "dev on behalf of Tom Scavo" <dev-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:
>
>> 1) Modify the behavior of boolean attribute
>> MetadataProvider/@requireValidMetadata: If @creationInstant exists and
>> is in the future, the metadata is not valid
>
> That would not be appropriate since the definition of valid metadata doesn't involve that attribute.

If @creationInstant is allowed to be in the future, then it is a
useless piece of metadata and that's the end of it.

>> 2) Add attribute MetadataProvider/@freshnessInterval (to complement
>> @expirationWarningThreshold, which is misnamed [1])
>
> I think more settings is a bad direction.

If I had to choose one, I'd choose @freshnessInterval for sure. The
other one is much less useful. By the time an expiration warning is
issued, it is too late.

> I'm also much more concerned about the limitations I've identified in the dynamic plugins to worry about aggregates. Until those issues are dealt with, there shouldn't be more time spent on the old way of doing things.

I understand your concern about dynamic metadata but that is
orthogonal. Everything I've said so far applies to entity metadata as
well.

Without @creationInstant, a metadata issuer can work around the
validity check in RequiredValidUntil. Suppose
maxValidityInterval="P14D". On day #1, the issuer creates N files with
identical content:

File 1: valid until day #14
File 2: valid until day #15
File 3: valid until day #16
etc.

On day #1, the issuer publishes file #1; on day #2, the issuer
publishes file #2; and so forth. Since all the files are identical (in
content), the issuer has quietly subverted the trust model. To prevent
this, the filter should compute the difference (@validUntil -
@creationInstant) and ensure this quantity does not exceed
maxValidityInterval.

Tom