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

[Tomasz Wolniewicz <twoln AT umk.pl>]

Hi Niels,
   registraionAuthority will become one of the main security features. 
The new MDS will not accept any entities if their registrationAuthority 
does not match that stored in the eduGAIN database along with all other 
contact information we have.
I could provide an interface to this database, allowing you to produce a 
JSON (or XML) structure based on the value of the registrationAuthority.
Doing the JSON part would be next to trivial, as I would simply pack the 
database result object.

Does this sound like something that could help?

The only thing to remember would be that while we make all effort to 
keep eduGAIN stable, we cannot give proper guarantee that we will not 
have a down time, therefore any automated tools that you build would 
need to take this into account.

Tomasz


W dniu 2014-08-01 11:25, Niels van Dijk pisze:
> 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

--
Tomasz Wolniewicz
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576