on-prem application

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2019-03-20 23:12]:
> But no, having some on-campus system I'm managing or we have staff
> managing going into InCommon's metadata is a pointless exercise. If
> it's not federated, it doesn't belong there unless it's operated by
> somebody that's not part of my organization.

I only meant (but didn't write) that the SP could get signed and
already-managed metadata for the IDP from the federation feed (MDQ,
perferrably with the aggregate sizes today) even if the SP is not in
the federation aggregate itself -- assuming the SP could even consume
and validate such a metadata feed, of course.

> I think all the campuses that have tried to leverage InCommon for
> their non-federated systems have generally regretted it at worst, or
> found it pointless at best, but I suppose it depends on how
> comfortable with scripting metadata generation one is.

So far I've simply refrained from registering & publishing
IDP-specific SPs into a federation aggregate as it does not benefit
from the scalaing federation provides, on principle but also due to
work load.
(We might make one exception with one party essentially acting as a
sub-registrar providing the fedop with a signed feed for these SPs
on behalf of the institutions these SPs are for respectively. Or on
behalf of the party responsible for the SPs, if you will.
This is for ExLibris "Alma" SPs, which possibly could have been
configured and rolled out using the same entityID and endpoint for all
customers but for reasons unknown to me were not. So dozens and
hundreds and -- globally -- thousands of IDP-specific SPs for one
service.)

-peter