 |
 |
> its a lot easier to change them (when necessary), or to move them..... thanks Steven. I think I can see how we can migrate now. It's just a case of knocking up some SQL to allow ePTI keyed to athens, to be keyed to, say, RefWorks. The only problem is every SP that was behind athens, will now "share" a user's ePTI. But they did that anyway when they were behind Athens. As for privacy, it doesn't exist. A lot of SPs behind athens, upon receipt of ePTI display an information gathering page where you have to enter your personal details, name, email address etc. Will they do this in the federation? I have no idea. I would expect them to honour the protocol and use attributes for this, rather than abide by some privacy law then just ask the user directly for their personal details. Seems this migration is a hard nut to crack. User intervention is out. It's far too complicated. As far as the users are concerned, they're accessing the exact same resource. I'd like to see someone explain to them why that exact same resource now thinks they're a new user and they've lost all their settings. Alistair On 25 Jan 2008, at 16:51, Steven Carmody wrote: > 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..... -------------- mov eax,1 mov ebx,0 int 80h