Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] eduGAIN-Discuss: Assessment of Tajikistan / TARENA Id Federation for eduGAIN membership

edugain-discuss AT lists.geant.org

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

List archive


Re: [eduGAIN-discuss] eduGAIN-Discuss: Assessment of Tajikistan / TARENA Id Federation for eduGAIN membership


Chronological Thread 
  • From: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] eduGAIN-Discuss: Assessment of Tajikistan / TARENA Id Federation for eduGAIN membership
  • Date: Thu, 5 Dec 2019 18:58:55 +0100
  • Organization: ACOnet

* Halil Adem <hadem AT noc.grnet.gr> [2019-12-05 18:06]:
> I suggest that the "Technical: Alisher Davlatov" should be removed
> and that the support and technical contacts, should not be bound
> with physical persons.

That's a solid recommendation in basically all contexts involving
(re-)publishing of contact daa.

E.g. we started out years ago with publishing personal contacts for
the SAML entities we registered (and even today most SPs will give you
only personal email addresses by default unless you nag and pester
them about functional/role addresses) but with increased
pressure/awareness about data protection issues we longer wanted to
publish other people's personal data as part of our federation
metadata.
(Of course you can have processes where those contacts will have to
agree to such processing but that isn't necessarily voluntary etc.)

Long story short: I still haven't finished the cleanup of all our
entities ridding them of any personal names or addresses.

IDPs have been done years ago (mostly because we have closer
relationships with our IDPs than with SP -- which in .at are largely
external) but I still have some 13 SPs left to do (mostly because I
haven't been persuing this with a high priority).

While you may have good reasons to keeping personal names and contact
addresses in an internal CRM-type system (though I feel that those rot
too fast and we're pretty much never contacted when someone leaves the
SP or joins, so it's down to change requests by the SP that we learn
about personnel changes) but there should be no reason to publish
personal data in metadata or websites.

We've added this requirement to our registration process years ago and
getting functional/role addresses from the start is much easier than
trying to get rid of personal data after the fact.

Best,
-peter



Archive powered by MHonArc 2.6.19.

Top of Page