>>> On 17/04/2007 at 11:30, in message
<000001c780db$6f0cc710$61bf5e0a@jisc3sbhnh>,
Nicole Harris <[log in to unmask]> wrote:
> Dear All
> 
> Thanks for all of the replies on this.  I think this is probably a
good time
> to launch a new outreach resource from my team, in the form of the
Access
> Management Blog!  We are hoping to use this resource to discuss some
of the
> more complex issues around federated access management.
> 
> http://involve.jisc.ac.uk/wpmu/jam/ 

Thankyou, duly bookmarked :-)

> 
> On setting up the blog, my very first post was on accountability. 
This area
> is very important for us and we want to get it right. .

"you must not re-issue a targetedID or PrincipleName to another member
of staff or student within 24 months and you must be able to declare
that you will not do this"


Would it be possible to split the requirement rather than lumping
PrincipleName and targetedID together?  I believe that at Dundee we will
be able to sign up to not reissuing the targetedID by using the unique
staff ID/Matric number provided that only a hash of this is made
available publicly.  However, if the PrincipleName refers to the local
UserID and must be unique over 24 months, this would present us with
some difficulties. 

As the targetedID would be the usual persistant identifier provided it
seems to me that this is the one that is more important and to which we
could agree.

The 24 months bit isn't really an issue as such, any time period would
be the same and would mean that we would need a holding pen for old
UserIDs.  We would have to ensure that not only did a new one not clash
with an existing one but did not also clash with the holding pen of
"recently" expired ones.  

Hence, what I'm saying is that _any_ requirement not to reissue an ID
will require some work (doable but still _some work_).

So the bottom line is:  I think I can now safely say we will be able to
sign on the dotted line that we will not re-use a targettedID _ever_! 
But the PrincipalName is a different matter.

Of course this all assumes that PrincipalName is the users actual login
ID - does it have to be?  Could it be like the targettedID, some
obfuscated version of the matric/staff code?

  
> 
> Finally, section 7.1.3.1 of the technical recommendations for
participants
> provides some useful information on targeted generation.  Again, I'd
be
> interested in hearing more on whether we should extend the advice in
this
> section.

"2. Storage. An alternative solution is to store all values of
eduPersonTargetedID ever issued. When a new value is required, this
database is checked to prevent reassignment."   

Well, yes, but, as Jon pointed out earlier:

"The Internet2 software only supports hashing on the fly. You can
presumably 
extend it, given sufficient Java skill, to support only computing the 
value once."

I'm not sure I feel brave enough to start hacking round with the code
right at the outset....


Sorry - I hope I'm not talking too much....
Cheers
Andy