Integration of Discovery Service

Peter Schober peter.schober at
Wed May 6 11:47:17 EDT 2015

* Chris Phillips <Chris.Phillips at> [2015-05-06 17:26]:
> Looking to the future I see an emerging trend to something similar to what
> LIGO has done -- discovery by region or arbitrary (research) groupings.
> Not just one, but many of them stemming from the same metadata but
> operated centrally.
> For example, only show me IdPs in Province X or Research consortium Y that
> have done something above and beyond the regular federation attribute
> release requirements and signalled as such in the metadata via entity
> categories.

But those are precicely the kind of use-cases a central discovery
service isn't fit for, as it would need to be signalled somehow what
the SP wants. Or what IDPs are eligible to even try accessing a given

The CESNET/ WAYF software does this (I thought I an english
version too somewhere but this should do for now:, where an SP can signal to the central
DS the list of federations, interfedations, IDPs, etc. it's interested
in. The pops up like DiscoJuice (and reportedly works fine on small
mobile devices) but depends on a local service.
IIRC using the SWITCHwayf in "embedded" mode will also allow the
SP-co-located DS to tell the central component about white/blacklisted

> If others say 'Hey, you can do that already by . . .' let me know.

DiscoJuice, SWITCHwayf "embedded", and CESNET-ds can do some of that
(not Entity Categories, though), as having a central component (i.e.,
the claim that his is what you want) but with SP-infuenced/decided
sets of IDPs requires some signalling that their architecture already

> If this style of Discovery appeals to others, reach out to me to let
> me know as well.

Milan was a great supported of /one/ discovery service (instance),
which many faces, but with his passing noone has picked up that
particular battle, I think.
And of course there are same-origin issues everywhere here, for no
good reason, IMO.  If you can do that on an per-SP basis, fully
self-contained, why "want" the central service model? Because you
already built it so that it's redundant? Having discovery naturally
integrated with application -- i.e., having decentralized discovery
-- is already redundant and as scalable as the applications that you
want to access them with, ultimately.

More information about the users mailing list