An open discussion list for topics related to the eduGAIN interfederation service.

[Scott Koranda <skoranda AT gmail.com>]

> * Scott Koranda <skoranda AT gmail.com> [2018-05-08 17:16]:
> > Would you consider also tagging the IdP with the "hide from
> > discovery" tag since the IdP is generally not discoverable?
> 
> No.
> 
> It needs to be discoverable in order for its own subjects to find
> their IDP. It is a full production-level service.
> 
> > Since some discovery services pre-load logos and the like, when the
> > IdP's endpoints are not reachable it can cause delays and less than
> > optimal behavior for the discovery service.
> 
> You're making three assumptions here:
> 
> 0. That the logo is referenced by URL, not included by value (data:
>    URL).
> 
> 1. That the institution would be hosting their mdui:Logos on the
>    not-publicly-reachable IDP webserver.
>    There's no good reason to do that and I would not register such a
>    logo URL. Instead a publicly reachable logo URL from their public
>    web site (not the IDP web server) is referenced in the metadata.
>    This is what I did in our case.
> 
> 2. That a firewall could not be configured correctly to send a RST
>    in that case instead of dropping all packages silently.
>    This one is slightly more difficult, mostly because the operation
>    of their firewall is fully beyond our control/influcence.
>    But I think (1) fully makes going there unnecessary.

I understand and I appreciate that extra steps you as the registrar
would take.

I am not, however, making any assumptions. I am explaining the reality
of the eduGAIN metadata aggregate today with discovery services in
production.

I would be grateful if more registrars could take the care that you are
taking or, if not, apply the hide from discovery tag.

In the meantime, we use pyFF to create our own MDQ service and we filter
those IdPs out ourselves.

Thanks,

Scott K