 |
 |
On Tue, 17 Apr 2007, Tim Hogg wrote: > 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? I think you are confusing eduPersonTargetedID (consistent, opaque pseudonym for the user that is different for each service provider) and eduPersonPrincipleName (persistent user identifier, consistent across all services). Advantages of the former include preventing collusion between SPs, and the fact that it's probably not DPA-style 'personal data' and is therefore easier and safer to process. Jon. -- Jon Warbrick Web/News Development, Computing Service, University of Cambridge