managing untrusted metadata

[Cantor, Scott]

> In your view, what will become of FilesystemMetadataProvider now that we
> have LocalDynamicMetadataProvider. Are there any use cases for the
> former?

It works better for dealing with metadata that's being changed a lot and if you're scripting everything anyway, it doesn't really make that much difference. Six of one for a lot of cases. Batches take more memory, but are also more efficient at runtime. I'm really just saying I would never, ever create a separate metadata resolver for every individual file, that's insane.

> If you have a link to the Unicon stuff (or someone from Unicon is listening in),
> please add to this thread.

I don't have a link. I think it's in Internet2's github, and I don't know how to get into it.

> Is this running on the IdP server or elsewhere?

My staging system. If you mean the GUI I think they envision that it could, but it probably doesn't have to. They're all Docker centric and I'm not, so I wouldn't trust my interpretation of how any of it is supposed to work.

> Do you have a relevant pointer (or pointers) into jira?

Not off the top of my head, they're filed with pretty obvious titles, and much of it's just personal opinion about how I think things should work. e.g. The dynamic plugins don't cache failure. That means you can't have more than one in a chain without too much overhead and it means the remote dynamic has to be at the end of the chain. The local one isn't as bad, but I want better control over refreshes and would rather see it cache failure also.

> Oh, okay, I thought you were handling some entities in federation metadata
> specially due to a perceived high probably of failure at some point down the
> road.

I configure around some of them if I have reason to, but that's not a trust issue, just an operational one.

The ones I care about are contracted services. If I'm using InCommon for that metadata, I stay relatively aware of what I'm doing, and I'll be adding tags via filters to get a lot of my current behavior expressed more declaratively. Ad hoc SPs are responsible for themselves.

As an example, if I made a (poor) decision to push an SP into InCommon that doesn't support encryption, I know I have to work around that and turn it off since they're forced to supply a key that won't actually work. But if an SP out of the blue decided to do that and then made the mistake of asking me to turn it off for them? Let's just say they wouldn't like my answer, but I'd consider that a fun day at work.

-- Scott