At 11:15 AM +0000 1/25/08, Alistair Young wrote:
>thanks Dom.
>
>It seems it's possible to share the value of eduPersonTargetedId
>among a group of SPs. So perhaps the way to maintain "state" across
>access methods is to share it among the Shibboleth to Athens gateway
>and RefWorks, ScienceDirect etc. Sharing it should provide a
>migration bridge from Athens to the Fed. Only testing will tell.
>I'll get on to RefWorks and get us added to their WAYF. Ah but
>they're not in the federation!
>
As previously noted by Alistair, the eduperson spec (and also perhaps
the UK federation rules?) talk about having unique
eduPersonTargetedId values for each IdP + SP combination. My
recollection is that the reasoning had to do with protecting
individual privacy -- this would prevent a set of providers (perhaps
owned by the same umbrella organization) from collating TargetedId
values across multiple services.
However, the situations that are being described here certainly seem
to be outside that set of concerns. Additionally, perceptions about
the value of personal privacy seem to vary from country to country,
and from individual to individual. So, again, there would seem to no
universal "right" answer.
I'd note that Shib v1.2 and v1.3 include rather rudimentary
implementations of eduPersonTargetedId. Essentially, values are
computed on the fly (they aren't stored). This makes it rather
difficult to move a person's values from one source/IdP to another.
;-) Some sites have invested the work to put a DB behind the IdP, and
store these values on a per-SP basis. My sense, tho, is that
relatively few sites have done this.
With Shib 2.0 (which went to RC1 status earlier this week), we
invested a lot of effort in making it easier for sites to deploy a DB
to store these values. Once you're using stored values, its a lot
easier to change them (when necessary), or to move them.....
|