>>> On Tue, Apr 17, 2007 at 8:36 AM, Andy Swiffin <[log in to unmask]>
wrote:
>>>> 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
Andy,
Not speaking from a position of having done this yet, isn't it just a case of assigning a unique number to each user? There is no need for this number to relate back to any other identity that the person might have and I think probably an advantage if it doesn't. As the user never needs to know or remember what the number is it can be quite large, it need only be known by your directory and the resource provider. When implementing AthensDA we considered in some way using some existing identity we had for people, perhaps student or staff Id number and a prefix, but there seemed little point, not doing so preserved privacy better, and we could assign one identity to a person who had multiple accounts for some reason. In fact we've never done that and the main thinking was that if the resource provide didn't need to know a person's username then why pass it on?
I can't see why you would deliver a different identity to each SP. I think that would be an nightmare to trace through if you had to find someone following a complaint if you had one. Isn't the idea to deliver a single identity to all SPs but be able to choose to some extent what information beyond a minimum that you release about people to individual or groups of SPs?
Or have I missed something?
Tim
|