From:  David Walker <David.Walker at UCOP.EDU>
Reply-To:  David Walker <David.Walker at UCOP.EDU>
To:  UCFEDAUTH-L at LISTSERV.UCOP.EDU
Subject:  Proposed agenda for Wednesday's conference call
Date:  Mon, 3 May 2004 15:52:32 -0700


Everyone,

Please remember Wednesday's conference call (9:00a, 510-587-6076,
ID:51002#, PW:0500#).  Here's a proposed agenda:

1.  UCnetID issues.
2.  Policy issues.
3.  Formal definition of our attributes.
     - UCnetID
     - Campus ID
     - Transaction ID (Datta has raised the issue of whether we really
       need this.)
4.  Anything else?

FYI, I've attached more explanation from Larry Woods on UCnetID
matching.  Also, there is a proposal for improving uDir at the very end
of "Identity and Authentication:  Next Steps," which is on our project
web site at:

  http://www.ucop.edu/irc/itlc/ucfedauth/CommonAuthNextSteps/CommonAuthNextSteps-2003-12-17.html

We can discuss this during Wednesday's call, probably as a follow-on to
our current project.

                                            David

-----Forwarded Message-----
> From: Larry Woods <Larry.Woods at ucop.edu>
> To: "Ma, Ying" <
yma at AIS.UCLA.EDU>
> Cc:
Chet.Burgess at ucop.edu, David.Walker at ucop.edu, David L. Wasley
> <
david.wasley at ucop.edu>
> Subject: Fwd: Re: UCNetID integrity issue at UCLA
> Date: Mon, 03 May 2004 14:45:27 -0700
>
> Ying,
>
> I may not have been too clear when I was explaining the effect of the
> uppercase hashed ssn in the student processing.  Normally, a hashed
> ssn that equated to nine blanks, nine zeroes, or nine 9's would not
> cause the same netid to be assigned to everyone with that hashed ssn,
> because my student processing bypasses that step if the hashed ssn was
> equivalent to one of those values.  However, my code used the
> lowercase hashed ssn values in testing whether to bypass that step.
> In UCLA's case, since the uppercase hashed ssn for nine blanks did not
> match my lowercase hashed ssn for nine blanks, my code went ahead and
> tried to find a match (and was successful) in my high-level root
> table.  Thus, you ended up with 1132 records with the same netid based
> on an early record that had a hashed ssn equivalent to nine blanks.
>
> Actually, I'm not certain that my explanation clarified things or
> not.  Let me know if you still have questions.   We'll still have to
> coordinate later when we'll make the switch to using lowercase hashed
> ssn (and hashed student ID) in your student file.
>
>  --Larry