Nicole Harris wrote:
> There are some really interesting questions here, and issues that
> librarians have been tackling with for sometime...I think the
> federated approach has just shined a brighter light on some of the
> problems that institutions have with meeting some faintly ridiculous
> clauses that publishers insist on.
> To look at some of the questions brought up here, I think an
> institution has to have a very clear definition of what it means by a
> student. If the students from other organisations are physically
> registered in the institutional directory for the period of the
> course in question, my opinion would be that they are a full student
> of the institution for the period of that course - with all that this
> entails. You might not want to make them a member of the
> organisation though.
Agreed that *each institution* has to have a clear definition of what
*it* means by a student, or a member. I'd go so far as to say that it
would be pretty nice if that definition was available to relying parties.
I don't think, though, that this automatically leads to any rational
expectation that this per-institution definition might be exactly the
same as anyone else's. Similar, certainly in broad terms, but never
I think we can all accept that the definitions in both eduPerson and
in the UK federation's Technical Recommendations for Participants for
the various affiliation values are not completely precise. I have a
couple of possibly contentious things to say about this:
1. this is not accidental
2. we should not try and "fix" this either by
2a. tightening up the definitions (very much), or
2b. inventing more values (at all)
To put it another way, it's my personal view that the vagueness of the
affiliation definitions is a *feature*. Because it's essentially
impossible to come up with a precise definition of, say, "student",
which will meet with agreement from all parties (UK federation
membership: 438 and climbing), that's not the intention. Instead, the
defined affiliation values are vague so that if both parties are
prepared to acknowledge that there is slop in the definitions, it's
actually possible to come to an agreement where none would otherwise exist.
If you want an analogy, colours are good: if you can only talk about
"blue" and "green" (or any other finite vocabulary) then sometimes the
greeny-blues and bluey-greens will be hard to distinguish. But when it
comes down to it, show someone "blue" and they'll likely be happy to
call it "blue" too.
This requires the relying party either to review and accept the
particular institutional definition of the affiliation values (where
available) or preferably to compromise by saying: actually, we accept
that your good faith definition of "student" is likely to be close
enough to what we had in mind that we won't argue about the edge cases.
Relying parties who are unwilling to compromise in this way (who, in
other words, want to impose a particular precise definition of "student"
or "staff" on identity providers) are therefore not going to be happy
with the vague definitions.
* I don't think they will be much happier with tighter definitions,
unless they happen to match what they first thought of,
* I don't think adding new values helps at all, unless you're prepared
to add an awful lot of new values, essentially one per service provider.
I thought Ross Hayworth's example was an excellent one:
> we have a licence with a major service provider that would allow
> access to staff who are "retired, with proof of 60 years in age or
I don't think any of us would be likely to feel that it would be useful
to either make that part of the definition of "staff", or to add that as
an affiliation value.
> The other way of distinguishing them might be
> to make use of the flexibility of the scope - so to have
> [log in to unmask] for the specific course that teaches
> external students. Of course, if the Service Provider wants to
> distinguish between different groups of users they have to be willing
> to accept and reject different scopes and not just accept them all as
> often happens!
This idea has come up a number of times as a possible solution for
various flavours of this problem. I'm not particularly keen on it
myself, partly because our original idea for more granular scopes was to
represent relatively small numbers of static things (schools,
departments) and partly because scopes need to be registered with the
There's an eduCourse schema that might prove more promising in this
area. I don't know that anyone makes much use of it at present, though.
I think my own preference for dealing with service providers with
specific requirements for which vague definitions are inappropriate is
eduPersonEntitlement. This implies that a service provider who feels
that a vague definition of studentness isn't good enough for some reason
would precisely define the semantics of their own value for
eduPersonEntitlement. They would then come to an agreement with each
identity provider that they are requiring to implement that definition
that each appropriate person would be given such an entitlement value on
accessing that particular SP. This is what is done for the restricted
content in Film & Sound Online, for example.
ePE values don't have to populated into institutional attribute stores;
they can be computed by the IdP in arbitrarily complicated ways (see
Matt Dunkin's comments about "isnotrealstudent=true") but there is
clearly still a burden here on the IdP. I don't think that the
technology is to blame for that; I think that's inherent in the idea
that an individual service provider *requires* arbitrary access
conditions to be met. It's obviously better in the long term for people
not to enter into contracts with (Nicole's term) faintly ridiculous clauses.
> i think that retired members of staff are perhaps a good case for
> making an argument for extending the values currently used, although
> I can see them being managed through the affiliate value.
Judging by the library-walk-in case, it would be very hard to get the
authors of eduPerson to accept any more affiliation values. I'm also
very nervous about adding UK-specific values in opposition to that
standard, which you may know is also enforced in the default
configurations of every Shibboleth IdP and SP. Obviously, we could all
change those configurations, but sometimes pain is nature's way of
telling you not to walk through the brambles.
It may be that we need some broad discussion about what kinds of thing
we, as a community, think fall into each of these vague categories. I
don't think it's likely to be as helpful in resolving the underlying
issue as people might expect, though.