Relying party parsing. Metadata providers

[Cantor, Scott]

On 3/20/14, 5:32 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Yea I realized that about an hour after I sent it.  I have a couple of
>ideas
>on how to deal with that - strictly speaking they were yours.  I'm not too
>terrified by them - yet.  Actually the SchemaValidation filter is probably
>the scariest one right now, but that may be because I've not looked at
>signature too closely.  I'll certainly be mailing around once I do have my
>mind around filters.

There's a legacy option in the validation filter for setting extension
schemas up, and I suspect we want to just remove that. We could deprecate
it, but it's unused (I pretty much guarantee it) and the SchemaBuilder
component now has more direct ways of setting up sources of extensions.

Probably the best option is to leave it in the schema and then just not
process it except by warning.

>> Which are deprecated? We may just want to pull them, since this is a
>>major
>> upgrade.
>
>On ResourceBackedMetadataProvider there is "maxCacheDuration" with the
>comment "This property is deprecated, use maxRefreshDelay instead"
>
>On HttpMetadataProvider, FilebackedHttpMetadataProvider and
>FileSytemMetadataProvider there is "maintainExpiredMetadata" with the
>comment "This is deprecated, use requireValidMetadata instead".

I think we should just make these breaking changes at this point,
otherwise it seems silly to deprecate anything. If not now, I can't think
when. These are trivial fixes during an upgrade.

>It looks as though these were deprecated as recently as May 2010  (SC-102)
>and release in September of that year (Shibboleth-common:1.2/IDP
>release2.2.0)

Were you using "recently" ironically there? ;-)

-- Scott