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

[Niels van Dijk <niels.vandijk AT surfnet.nl>]

Hi all,

We currently seem to have no machine readable way of expressing metadata
on the interfederation federations themselfs. The edugain metadata does
publish a statement on RegistrationInfo

e.g.:
<mdrpi:RegistrationInfo
registrationAuthority="http://www.surfconext.nl/";
registrationInstant="2013-03-20T12:22:05Z"><mdrpi:RegistrationPolicy
xml:lang="en">https://wiki.surfnetlabs.nl/display/eduGAIN/EduGAIN</mdrpi:RegistrationPolicy></mdrpi:RegistrationInfo>

or
<mdrpi:RegistrationInfo
registrationAuthority="http://ukfederation.org.uk";
registrationInstant="2014-07-01T15:25:50Z"><mdrpi:RegistrationPolicy
xml:lang="en">http://ukfederation.org.uk/doc/mdrps-20130902</mdrpi:RegistrationPolicy></mdrpi:RegistrationInfo>

The information on the registrationAuthority is not machine readable.
Also, there is no machine readable information available on the
'authoritative contacts' for a federation. (comparable to the contact
data we publish in our metadata for SPs and IdPs).

I can think of a number of use cases:
1) We are building trust frameworks like e.g. CoCo and the R&S bundle
which rely on the federation operator to issue statements on the
'trustworthiness' of an entitie. I have however no means to contact the
federation operator that issued that statement based on the information
provided. I could try to find these details on the page of the
registrationAuthority, but these pages are mostly targeted at the local
audience, so e.g. primarily available in the local language. Browsing
these pages does however also reveal that most federations do provide
such contact details at some place on these websites as public data. So
there seems to be no reason not to have these in a public metadata
registry as well.
2) If we want to automate incident response of cause primarily the SP or
IdP is involved. There are however scenarios where the federation
operator is/should be involved as well. How can these be reached, other
then via the 'old boys' network (which is very good for trust, but
scales rather poorly)?
3) In this grand age of community cloud <irony detection off>, I want to
offer a service to fellow federations. Suppose I want federation
operators to be able to do stuff, how do I get an authoritative
statement on who these people are?

I think therefore, federation operator contact data (admin/tech/support)
should be contained in signed metadata, just as we have contact data for
SPs and IdPs. Perhaps as part of the eduGAIN metadata stream, perhaps
(my preference) as part of a separate stream that simply publishes
participating federations and data on these.

Any thoughts or comments?

Cheers,
Niels