On second thought, I think I'm just going to implement an actual metadata filter for this outright because in most cases the logos are causing a double hit to both the discovery feed and also resident memory for the metadata itself, and it's clearly substantial. Getting rid of it outright probably makes the most sense here and is more modular code-wise.

Best way to do this is probably along the lines of the old legacyOrgNames setting, i.e. put it on the metadata providers that are discoverable, and just add a boolean for whether to include them.

This is just a RFE. We asked somebody to file this but they ended up confusing this with a less clear request and it never got filed.

The only other thing I'd note about it is that we really don't see the SP as the right way to drive discovery, it's too limiting and prevents moving to the modern on-demand metadata sources people should be switching too. The InCommon aggregate isn't going to be there forever.

To that end, we're really encouraging doing this outside the SP, so in fact you may already have a solution you should stick with. Native code is not a good replacement for scripts people already have.

Some other points:

• there's seamlessaccess.org, though that only works for cases where your list of IdPs is from eduGAIN, and I suspect that's too limiting for you, or frankly, just about anybody

• there's also our Metadata Aggregator

We have started working up prototyped configurations for the MDA software to use it to munge the aggregate and produce a metadata feed that's compatible with the EDS. So to the extent that we support a solution longer term in our software stack, it's likely that approach.

But I don't have any problem implementing something as long as it's got a simple heuristic.