SP V3 metadata types

Tom Scavo trscavo at gmail.com
Tue Jun 12 09:45:18 EDT 2018


On Mon, Jun 11, 2018 at 3:57 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> I'm not sure your idea of "smarter" matches mine, I just asked for some particular caching and change detection improvements and I think they're underway. They aren't attempts to turn "remote" into "local". People don't cache DNS that way, and this is the same, you either trust a remote source or you're paranoid (possibly for good reason) and want to do it all yourself, in which case you can just script up your own folder to taste and use LocalDynamic. I don't think there's sufficient demand for us to bother with that. I think we implemented (or have in progress) all the improvements that were suggested by the InCommon WG).

I don't agree with all of that, but in any case, I'm beginning to get
your drift. As a compromise, I added a couple of "TIPS" to the section
on Remote Metadata on the MetadataManagementBestPractices page. [1]
The tip in the DynamicHTTPMetadataProvider section reads as follows:

<tip>
Ask your federation operator how best to configure a metadata provider
of type DynamicHTTPMetadataProvider. In particular, determine the base
URL of the MDQ server, Also ask about the recommended values of the
minCacheDuration attribute (default: PT10M) and the maxCacheDuration
attribute (default: PT8H). Finally, ask how best to configure the
provider to mitigate the risk of an MDQ server that is unreachable or
nonresponsive.
</tip>

I'm guessing that's closer to what you had in mind, that is, the
deployer should be advised to consult the federation operator.

Comments welcome.

Tom

[1] MetadataManagementBestPractices
https://wiki.shibboleth.net/confluence/x/JQXKAg


More information about the dev mailing list