Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs

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 and non "academic" IdPs


Chronological Thread 
  • From: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] eduGAIN and non "academic" IdPs
  • Date: Thu, 4 Dec 2014 10:55:28 +0100
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>
  • Organization: ACOnet

* Martin Matthiesen <martin.matthiesen AT csc.fi> [2014-12-03 12:40]:
> If my contract says: Open for "academics in good standing" without
> registration (explicitly excluding students) and all parties accept
> that there are slight differences in definition, I see no
> problem. We don't need to overengineer here.

It's doubtful RPs will actually be willing to leave that wide open to
everyone's interpretation, but if you say so and I believe you're able
to speak on behalf of the community this use case is for, that's fine.

> > What I'd like to see is a sufficiently detailed writeup of the
> > requirements of the license agreements in your use case, in a way that
> > can be easily operationalzed globally and federation operators can
> > help institutions the world over to map local/internal data structures
> > onto a shared eduPersonEntitlement value for your use case.
>
> I don't have a copy at hand, and if I had, I would not want to go to
> that level. The agreement allows for "faculty", it might allow even
> for "employee".

Does it include "student"? If so can we agree here and now that
"member" (cf. eduPerson defintion) is good enough?
>From any IDP (representing any number of any kind of institution, as
long as the institution is eligible for federation membership for a
given registrar, for all member federations of eduGAIN)?

Examples from Wikipedia (mentioned by Nicole yesterday at the EWTI
meeting):

"Academia is the nationally and internationally recognized
establishment of professional scholars and students, usually
centered around colleges and universities, who are engaged in
higher education and research."
http://en.wikipedia.org/wiki/Academia

"Academia" clearly DOES include students (of HE institutions).
Further down that page it says this:

"An academic is a person who works as a teacher or researcher at a
university or other higher education institution. [...] An
academic usually holds an advanced degree.
http://en.wikipedia.org/wiki/Academia#Academic_personnel

So "acadeic" clearly that DOES NOT include students, it's closest to
the north american use of "faculty":

"Most university faculty members hold a Ph.D. or equivalent
doctorate degree."
http://en.wikipedia.org/wiki/Faculty_(academic_staff)

So I would suggest the following (eduPerson affiliation values):

* Require just "member", if you're fine with students being included

* Require "member AND NOT student" if you're not fine with students

* If for some reason that's all unacceptable, require "faculty" and
find ways how to deal with those not sending it (e.g. by accepting
"staff" instead, as the UKfed and eduID.at use that to include
faculty).

You still need a way to deal with subjects from IDPs (representing one
or more institutions) which are not universities (or publicly funded
research institutions, not that we tag those today or that the funding
body is part of your "definition" above). Does that include their
employees as well (if not all, which ones)? If there's no attribute by
which RPs can recognize those -- and eduPerson is not seen as suitable
for those, see the discussion on MACE-Dir I started for this this week
-- how would you do vetting of individuals from across the globe?


> Agreements require interpretation too, as most lawyers would be out
> of work otherwise. But that in turn requires that these attributes
> are half-way defined and used as defined. And set in the first
> place.

Right. You could require "faculty" (which seems closest) but then
you'd lose out on several whole countries where use of that north
american term is not common (or used at all).

I have no opinion on whether it's worth trying to get more regions of
the world aligned to north american terminology and what time frame
(years, in unsigned integers) you'd find acceptable. As I said before,
e.g. in .at we've started the process of suggesting to institutions to
differentiate between staff (used here like it is in the UK) and
faculty (in the above Wikipedia sense). Others may not have such plans
today.

> What we need is an understanding of a proper process that is a bit
> more binding than the present one.

eduGAIN (as a service) is a metadata exchange service between R&E
federations (mostly, there's also the lightweight policy package),
built in the assumption that changing member federations' policies are
out of scope. The eduGAIN and REFEDS communities do coordinate and
exchange experience and standardize things, but neither are in a
position to mandate institiutions doing things (or what? Expell them
if they don't assign "faculty" in their IDM?).
I don't see how anyone in the world would ever be in a position to
force an institution to release data (and even affiliation is PII in
some jurisdictions) to anyone. "You have to or you can't access the
service", sure, you can do that today.

Not sure how to move forward if the above suggestions on attribute
requirements for your use case are not acceptabe.
-peter





Archive powered by MHonArc 2.6.19.

Top of Page