Subject RE: Re: eP(S)A comparison
From "Andrew Cormack" <Andrew.Cormack@xxxxxx>
Date Fri, 28 Aug 2009 14:13:02 +0100

> -----Original Message-----
> From: Peter Schober [mailto:peter.schober@xxxxxxxxxxxx]
> Sent: 28 August 2009 12:57
> To: refeds@xxxxxxxxxx
> Subject: [refeds] Re: eP(S)A comparison
> * Andrew Cormack <Andrew.Cormack@xxxxxx> [2009-08-28 09:25]:
> > What I was trying to get at were the automatic subsets - e.g. if I
> > am "faculty" then I am also "member" - since differences there
> > seemed to have the most potential for messing up service providers.
> Actually sets (of sets) shouldn't be relevant -- which is why I did
> not take this any further back in 2007.  Instead, *all* affiliations
> that apply should be released for a given person. Service Providers
> then maybe don't have a single piece of data to require, but get more
> control in turn.
> By not aiming at the relations between those terms but at the
> invidivual affiliations themselfs we don't get into the game of
> incompatible hierarchies. *But* we'd still have to roughly agree on
> those basic affiliations (e.g. an employee is on an institutions'
> payroll and will usually be shown in institutional directories -- or
> whatever, I am making this up).

It was the difference in hierarchies that alerted me to the fact that
there appeared to be a fundamental difference between us and HAKA. That
has been relatively easy to spot and understand.

But I suspect that looking at the remaining definitions and working out
whether they are actually identical will be a much harder job and need
knowledge of many more languages than I have, because you won't just be
looking at the definitions, you'll need to understand local differences
in the terms used in the definitions, like the US/UK difference that has
emerged in the meaning of the word "staff". :-(

But the more optimistic view is that maybe it doesn't matter. I suspect
that the vast majority of access control requirements are covered by
"member", and "group defined by enumeration": the latter covering things
like "the tutor and students in tutorial group X" (and, as a degenerate
case, the group "Andrew") and being defined either at the SP side by
ePPN or the IdP site by ePE. "Faculty" and "student" may be useful, but
as others have pointed out there are a very large number of people who
are both, so making something visible to one group and not the other
isn't going to keep many secrets!

And while "group by enumeration" has to be accurate, the real world has
sufficient fuzzy cases to make me think that a bit of fuzziness in the
other classes may be something we have to accept even if we were to
agree perfectly on the definitions in the digital world.
> Maybe this is undoable as well on a global level, but if we don't
> agree on the basic building blocks, how does studying the differing
> relations these incompatible terms have will produce much insight?
>   If this is what's already happening, I think we need to shift our
> focus away from "extensional definitions" (what affiliations are
> "included" by what other affiliations) to "intensional definitions"
> (what are the basic characteristics we're after, when we say
> "student").
> Also eduPerson is not written in stone, so besides expanding the
> controlled vocabulary, maybe (just maybe) the definitions/intensions
> of some of those values could rely slightly less on intuition and
> local interpretation in the future? OK, you may stop laughing now ;)

I'd hope that documenting the meanings of the existing values is
entirely practical. Indeed we've very nearly done in it in the past
couple of days :-)


> -peter