Subject Re: Re: eP(S)A comparison
From Keith Hazelton <hazelton@xxxxxxxxxxxxx>
Date Fri, 28 Aug 2009 11:47:48 -0500

Comments below.
On Aug 28, 2009, at 08:13, Andrew Cormack wrote:

-----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

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 :-)



Re Andrews last point, I'd really like to see if we can incorporate clarifying language on the meanings of existing values into the eduPerson spec itself.

         --Keith Hazelton