>>> On 16/04/2007 at 17:42, in message
<[log in to unmask]>,
"Dennison,
Karen J" <[log in to unmask]> wrote:
>
> However, despite the fact that this attribute is described in the
> documentation as being being "A persistent, _non-reassigned_,
> privacy-preserving identifier [...]" this does not mean that IdPs are
bound
> to the non-reassignment principle. I have been informed that asking
> institutional IdPs to implement eduPerson non-reassignment would
require most
> IdPs to modify their existing institutional administrative processes
for
> assigning login names to users of their campus SSO systems and was
therefore
> deemed to be a non-starter.
>
Hi
I'm glad you raised this as its one of the (many) areas that I'm still
a little confused about. Maybe this will become aclearer when I
actually get to the stage of deploying the IdP, but:
The Identity Provider Deployment document from the "Federation" site
says:
"eduPersonTargetedID. this attribute provides a consistent, opaque
pseudonym for the user that is different for each service provider"
How does that work? I would imagine we hash the userID and store
that away in a directory attribute which is made available to the IdP
but that is just one value, if it is different when delivered to each SP
who makes it different?
Responding to what Karen said - we are one of the majority of
institutions that do re-use user IDs, so could not sign up to the
non-reassigned clause. But, could we not attach, for example, a year
indicator to the userID thus making it unique and then hash that and
store it in the eduPersonTargetedID attribute? So for example should I
leave Dundee and another alswiffin turn up a couple of years later, even
though their local login ID would be the same, i.e. alswiffin, for the
purposes of eduPersonTargetedID I would have been a hashed alswiffin2007
and they would be a hashed alswiffin2009 hence unique.
Or have I totally misunderstood this?
Cheers
Andy
|