Thanks for the replies on this, useful things to think about:


>>>, Alistair Young wrote:
> a chap I met once said that if middleware is ever noticed, it's  
> failed. If you have to change your business processes to fit with the
 
> current middleware fad, then it has failed spectacularly.
> 
> A side effect of adding a year modifier to your userid is your users 

> jump up and down every year, when they have to remember a new userid 

> and all those settings they customised at all those SPs last year  
> will disappear this year, as the SP now knows them to be a new user.

Oh heavens, no!!  I didn't mean change the actual userID  (or
eduPersonPrincipalName I should now refer to it as!), that would stay
the same as ever and the users would never actually see the modified
form.   The modified form would only be created once too, i.e. it's at
creation time that the year suffix could be added to distinguish it from
previous incarnations of initial surname combination, it would then stay
as that for the lifetime of the user,  It would be a permanent fixture
and wouldn't change.

Tim Hogg <[log in to unmask]> wrote:

>  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, 

Hi Tim,  I guess all the old crowd are going to turn up on here sooner
or later :-)

Yes, of course, you're right there is no need to base this attribute on
the userID, the only constraint is that it be unique.  We have
guaranteed uniqueness already in the student matric number and staff ID
so it makes sense to hash those - it will be "opaque" anyway so no need
to start with something identifiable.  My worry about uniqueness (or
actually non uniqueness) of userIDs was a red herring, I think.

In fact now I think about it - this is what the library IT staff do
already to provide the AthensID, hash the staff/matric code.    Karen -
I recant my previous statement, as far as eduPersonTargetedId is
concerned Dundee will be saying it won't be reassigned.


> 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?

You might have.  The requirement for uniqueness between SPs is
specified in the documentation, the UKFed  "Recommendations for the use
of Personal data" says:

"3.2.2 eduPersonTargetedID
Identity Providers should provide different eduPersonTargetedID values
to different Service Providers: this protects the user against collusion
by Service Providers to derive or exchange additional information about
the user."

Jon Warbrick<[log in to unmask]> wrote:
> One approach is to hash user identifier, SP identifier, IdP
identifier, 
> and a secret. The Internet2 reference implementation includes support
for 
> doing this out of the box. Opinions vary as to whether it's better to
do 
> this on the fly every time (which requires no back-end storage), or
to do 
> it once when each tuple is required and store the result.

OK, thanks Jon, so the IdP software can do this kind of stuff for us on
the fly- this is where I think I'm needing to get my hands dirty and
actually start looking more closely at the software and what it can do.

If you do the hash once for each SP instance and store it, how is it
stored, does the IdP refer to a directory multivalued attribute stored
in some form of key:value pair or something like that?

Cheers
Andy