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

[Ian Young <ian AT iay.org.uk>]

On 7 Jul 2014, at 10:52, Tomasz Wolniewicz <twoln AT umk.pl> wrote:

> I expected this much, in this case I would expect that a separate eduGAIN 
> feed, or even and option - take just the UK Feed or another one which is 
> aggregated with UK could be easer for them to handle.

This all comes down to what you think the long term future of eduGAIN will 
be; and, because what you design for is what you will get, that in turn 
depends on what you *want* the long term future of eduGAIN to be.

If you want the long term future of eduGAIN to be a thin connection between 
participants which will only be used by a small number of people, then you 
design for separate aggregates and opt-in at all points. Yes, it's "easier" 
for people who are not involved in eduGAIN, but it adds friction to the 
process and the result will be that wide participation in eduGAIN is 
extremely unlikely to happen. In other words, this kind of approach becomes a 
self-fulfilling prophecy.

If you want eduGAIN participation to be the rule rather than the exception in 
the long term, then of course you design differently.

> I wonder what mess we will get into when the same SP starts getting the 
> same entities from several federations that this SP is a member of.

I'm sure that has already happened. To the extent that an SP gets the same 
metadata from each source, you might see some duplicates in lists depending 
on implementation but that should be all. Of course if an entity has 
different metadata in different federations then additional problems arise, 
so we should try and avoid that. Long term, of course, the best approach is 
to use eduGAIN and interfederation rather than registering in multiple 
federations.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature