Main Nav

I hate to start another SSN thread on this list (see Jan 2011 and Jan 2008), but I will try to constrain the topic. UW is one of those sites that has a "person registry" driving its enterprise IdM, providing identities for accounts, authorization, etc. This UPR gets the usual feeds from source systems (HR, student, alum, extension, partners) and as one of its jobs tries to match person data coming from the different sources. In our case one of the main items we match on is SSN; we get SSNs from the student and HR sources. UW, probably years behind other campuses, is moving toward having a comprehensive enterprise SSN-handling policy. This new doc sets out the acceptable situations for obtaining and using SSNs, driven primarily by federal and state law and regulation. Processes like hiring and student financial aid require SSN, by law, so are explictly permitted. Identity management matching is not required, so is a point of contention. Our IAM team is seeking explicit permission for our long-standing practice. Some other policy-drafting participants are pushing back, saying that SSNs can only be used for this purpose if individuals give their permission (ie, opt-in). (It is notable that use of SSN for matching student applicant records between institutions is another non-mandated practice that is seeking, or may already have, this exemption.) So, we're curious whether IAM operations at other campuses have been subject to pressure to remove SSNs, or obtain user permission to use them (which seems hopeless to me), and whether your operations have changed as a result. We're not asking, today, about alternative matching approaches, or ways of protecting SSNs (but of course discussion will go where it will). Thanks, - RL "Bob" Morgan UW-IT IAM

Comments

Hi RL, We engaged in a similar debate at Cornell a couple years ago in response to complaints about our practice of requiring SSN's to create NetIDs for sponsored individuals. These are typically people who are doing work that supports the University's mission but are not on the payroll or not enrolled as students. Here is the information we developed for an FAQ to document the reasons for viewing this as a legitimate business practice and to inform people of how we safeguard the data: Why do I have to provide my SSN to obtain a sponsored NetID? CIT has a legitimate business need to obtain social security numbers for individuals who require a sponsored NetID. This data element is key in helping us manage identity records for the campus community. It reduces the incidence of mismatched records (i.e. merging two records for different individuals into one) and duplicated records. Mismatched or duplicated identity records can result in exposure of data to unauthorized individuals and significant inconvenience for the user. Exceptions to the SSN requirement are possible if the sponsoring department can locate a record for the individual in PeopleSoft. In that case the unique CUid (formerly referred to as 'Employee ID' or 'EmplID') can be provided in lieu of the social security number, along with the other materials required to approve and generate a NetID. How does CIT mitigate the risk of collecting SSN information for the purpose of generating a NetID? The SSN CIT collects as part of generating a sponsored NetID is not used for any purpose other than ensuring proper record creation, and it is not incorporated into our general business systems. We safeguard this data in accordance with the requirements for classified data set forth in Policy 5.10, Information Security . -- Andrea Beesing Assistant Director, Infrastructure Cornell Information Technologies 110 Maple Ave Cornell University (607) 254-7441 amb3@cornell.edu
I believe that identity management matching IS required; and I believe that the use of SSN in IdM matching logic is critical. It is my opinion that, as long as SSN's remain protected and are not made available to other systems, matching is a legitimate internal use. Here is a quote from the relevant UT System policy: http://www.utsystem.edu/bor/procedures/policy/policies/uts165.html 10.1 All Entities shall reduce the use and collection of social security numbers. 10.1.1 All Entities shall discontinue the use of the social security number as an individual's primary identification number unless required or permitted by law. The social security number may be stored as a confidential attribute associated with an individual. 10.1.2 If the collection and use of social security numbers is permitted, but not required, by applicable law, the Entity shall use and collect social security numbers only as reasonably necessary for the proper administration or accomplishment of the their respective business, governmental, educational and medical purposes, including, but not limited to: 10.1.2.1 As means of identifying an individual for whom a unique identification number is not known; 10.1.2.2 For internal verification or administrative purposes; By way of an example where use of SSN is critical... We have (or had) a real circumstance where twins were participating in the same Residency program. Being same gender twins the only data distinguishing them was first name and SSN. We are fanatic about protecting SSNs that exist in our Registry. We do not require SSN but use it for matching if it is available. The consequences of discontinuing the practice of using SSN for matching would be an increase in false positive matches (the most difficult error to fix) and an increase in ambiguous matches (which require manual intervention to resolve).
We were collecting SSN for a similar group of users but changed to collecting Driver License number/state of issue or passport as a result of the SSN policy we adopted.
Message from les.lacroix@carleton.edu

We don't use SSN within our identity management registry. I guess we've gotten away with it by "outsourcing" identity matching to the owners of the major information systems (admissions, student information and payroll, and alumni/advancement), where there are separate bi-lateral processes to share person information. The student+payroll system holds the alumni/advancement ID for a person; the alumni/advancement system also holds the student+payroll ID for the person. Similarly, we back-feed the student ID to the admissions system. I'm sure that those bi-lateral processes share SSN for identity matching; but once it's matched and the foreign keys are saved, I don't have any need for SSN. A small number of duplicates do occur every year, but that's usually because of a broken process on another part of campus that my identity management processing won't fix. The exception to the "small number of duplicates" rule is for library walk-ins. They are issued pre-printed, anonymous campus ID cards from the library, not the campus ID office, and then their name and address is entered into the card ID system. The library issues these cards to staff/faculty family, among others. At a later time, someone with a "library card" may be hired or take classes. We do not have a policy in place to retrieve these cards when someone gets a full-featured staff or student ID, and we've never had a problem; at least, a problem that needed resolution within the identity system. -Les __________________________________ Les LaCroix | Strategic Technologist and EIS Team Lead Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057 507.222.5455
UChicago has adopted what I hope is a pragmatic approach to this issue. The central IdM operation continues to incorporate SSNs for two purposes: 1. Providing the SSN <-> ChicagoID translation service needed to enable abatement of SSN usage in myriads of systems. 2. Identity matching for on-boarding processes that inherently must rely on it, and for other on-boarding processes until their use of SSN can be abated. We've built a web service to integrate with on-boarding processes that do not use SSN. This enables us to incrementally abate SSN use from on-boarding processes as opportunities to do so arise. Our first such attempt has been put on hold, though the approach has been successfully vetted. With approximately 30 distinct on-boarding processes around the university, we'll be abating SSN use in that context for a long time. Tom -- Tom Barton Senior Director for Architecture, Integration, and Security Chief Information Security Officer Information Technology Services University of Chicago +1 773 834 1700 (office) On 4/12/2012 6:41 PM, RL 'Bob' Morgan wrote: > I hate to start another SSN thread on this list (see Jan 2011 and Jan 2008), but I will try to > constrain the topic. > > UW is one of those sites that has a "person registry" driving its enterprise IdM, providing > identities for accounts, authorization, etc. This UPR gets the usual feeds from source systems > (HR, student, alum, extension, partners) and as one of its jobs tries to match person data > coming from the different sources. In our case one of the main items we match on is SSN; we > get SSNs from the student and HR sources. > > UW, probably years behind other campuses, is moving toward having a comprehensive enterprise > SSN-handling policy. This new doc sets out the acceptable situations for obtaining and using > SSNs, driven primarily by federal and state law and regulation. Processes like hiring and > student financial aid require SSN, by law, so are explictly permitted. Identity management > matching is not required, so is a point of contention. Our IAM team is seeking explicit > permission for our long-standing practice. Some other policy-drafting participants are > pushing back, saying that SSNs can only be used for this purpose if individuals give their > permission (ie, opt-in). (It is notable that use of SSN for matching student applicant > records between institutions is another non-mandated practice that is seeking, or may already > have, this exemption.) > > So, we're curious whether IAM operations at other campuses have been subject to pressure to > remove SSNs, or obtain user permission to use them (which seems hopeless to me), and whether > your operations have changed as a result. We're not asking, today, about alternative matching > approaches, or ways of protecting SSNs (but of course discussion will go where it will). > > Thanks, > > - RL "Bob" Morgan > UW-IT IAM
Message from atlunde@panix.com

At Northwestern University, we've had a policy on use of SSNs for several years: http://www.it.northwestern.edu/policies/SSN_policy.html We've got two PeopleSoft systems for Human Resources and Student Records, and an identity management system that merges information from them. We have SSNs in the PeopleSoft and Identity Management systems, but we are trying to not export them further. The SSN is optionally used among those systems for matching records. A "fake" SSN of several kinds may be assigned for records that don't have real SSNs. Our LDAP "registry" and Active Directory systems are down-stream recipients of data, used to distribute data in-house to other systems. Shibboleth is used for third-party off-campus vendors. The SSN (real or fake) doesn't go to any of those systems. (Our white-pages directory LDAP and web site is a partial replica of the LDAP registry.) The common keys for most other in-house purposes are an alphanumeric "netid" and/or a numeric "emplid". The emplid is the closest replacement for the SSN, being a unique, non-reassigned numeric identifier. The netid is the "username" for various purposes. We are trying to obscure it when we can, but because so many protocols leak such information, it can't be regarded as a deep secret. (Email addresses are another parallel universe.) The identity management system matches records on emplid and/or SSN, not on other attributes like name. If I were redesigning from scratch, I'd say we had too many unique keys, and too many sub-cases that exist only for legacy reasons. Having some records with SSNs and others without leads to records for the "same" person not always matching, and messy manual fix-ups. We are trying to grant access to data in-house on a "need to know" basis, but how granular than can be depends on the technology. -- Albert Lunde albert-lunde@northwestern.edu atlunde@panix.com (address for personal mail)
On 4/12/2012 6:41 PM, RL 'Bob' Morgan wrote: > So, we're curious whether IAM operations at other campuses have been > subject to pressure to remove SSNs, or obtain user permission to use > them (which seems hopeless to me), and whether your operations have > changed as a result. We're not asking, today, about alternative matching > approaches, or ways of protecting SSNs (but of course discussion will go > where it will). We've not to my knowledge been asked to remove them from our person registry, though we have been asked to remove them from various processes surrounding it (e.g. helpdesk searches to find directory entries for password reset purposes). We actually do keep it in our directory, as there are applications that have legitimate business needs for it. One of the most obvious examples is our outsourced W2 reprint vendor, for which the SSN is the primary identifier expected to be passed as a SAML NameID. But the bar for releasing SSN is pretty high at this point (and it needs to be signed off on by the data custodian (HR) before we will release it, just like any other private data). Our upcoming IDM project would be a good time for us to review our use of SSN for matching. I believe we collect it for "sponsored" accounts like Cornell, but Texas' idea of switching to driver's license/state ID sounds interesting. -- %% Christopher A. Bongaarts %% cab@umn.edu %% %% OIT - Identity Management %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %%
Message from mcallister@missouri.edu

> From: Identity Management Constituent Group Discussion list > [IDM@LISTSERV.EDUCAUSE.EDU] on behalf of RL 'Bob' Morgan [rlmorgan@WASHINGTON.EDU] snip > So, we're curious whether IAM operations at other campuses have been > subject to pressure to remove SSNs, or obtain user permission to use them > (which seems hopeless to me), and whether your operations have changed as > a result. We're not asking, today, about alternative matching approaches, > or ways of protecting SSNs (but of course discussion will go where it > will). The University of Missouri does not use SSNs in IAM operations. In 2007 the University suffered a security breach which resulted in the documented theft of 22,000+ student/staff SSNs out of our trouble ticketing system. The SSNs were stored in the trouble ticket system as part of standard feeds from student and HR databases. They were used as a way for HelpDesk personnel to identify users and troubleshoot identity problems. Needless to say the breach caused quite a stir and opened a lot of eyes to the problem of "data leakage" in systems where the numbers are used only for identity matching and no other purpose. For this reason, we do not use SSNs in our IAM systems. In fact, we have removed SSNs from our HR, Finance and Student systems entirely. Instead we keep all the institution's SSNs in a highly secured electronic "vault". Our administrative applications store an alternate identifier (AltID) in their databases. When data is sent to external entities, the AltIDs are switched out with the real SSN as part of our secure file transfer process. When data is imported or hand-entered into our administrative apps, the SSNs are automatically stored in our vault and an AltID is generated and stored in the administrative application in its place. As a general rule, and in accordance with the 1974 Privacy Act, we try very hard not to collect or use SSNs from individuals unless there is a specific legal reason to do so. Account management doesn't fall into that category. We hold a large number of SSNs in our "vault" and a rudimentary analysis shows that roughly 1/6th of them are unreliable or "dirty" data. In my opinion, other institutions that use SSNs as some sort of measure of "true" identity are overlooking the fact that many students and even some employees do not provide their correct (or even a consistent) SSN when asked. Think of this trend like the "fake phone number effect". That's where people give out a fake phone number to avoid calls from annoying blind dates or telemarketers. Andrew McAllister SSN Team University of Missouri
On Mon, 16 Apr 2012, McAllister, Andrew wrote: > For this reason, we do not use SSNs in our IAM systems. In fact, we have > removed SSNs from our HR, Finance and Student systems entirely. Instead > we keep all the institution's SSNs in a highly secured electronic > "vault". Fascinating. Teachable moments can be very powerful. 8^) Is the SSN vault a homegrown system or a commercial product? Thanks, - RL "Bob"
Seems like a slight over reaction to the security breach to me. I do see storing SSNs in the trouble ticked system as a problem. Using SSN for identifying users is not appropriate and also not reliable. But I would not equate what is described as identifying users as it relates to a trouble ticket system to 'Identity Matching'. Our Registry is "highly secured" and SSNs do flow in but they do not flow out and the security for HR, Finance, and Student systems should all be "highly secured" for reasons not limited to storage of SSN. Pulling SSN out of systems with legitimate needs to use that identifier really seems like overkill to me. I would assume that SSNs given as a requirement for employment or for financial aid would be more accurate than the 1/6 unreliable statistic stated below, but even if this statistic holds our experience is that if we have SSNs that match for two identities they are 99.9% of the time referring to the same person.
Message from mcallister@missouri.edu

> Seems like a slight over reaction to the security breach to me. We made the national news. This was not a missing hard drive or lost laptop; the people that stole our data got what they came for. We lost a great deal that day, not the least of which was our reputation and the trust and good will of those affected. > I do see storing SSNs in the trouble ticked system as a problem. Using SSN > for identifying users is not appropriate and also not reliable. But I would not > equate what is described as identifying users as it relates to a trouble ticket > system to 'Identity Matching'. Matching a person on the phone to one or more accounts in our systems is what I was talking about. That's how I interpreted "identity matching". In 2007 SSNs were part of the identity verification process. All of this seems absurd today, but not so long ago it was standard practice. > Our Registry is "highly secured" and SSNs do flow in but they do not flow out > and the security for HR, Finance, and Student systems should all be "highly > secured" for reasons not limited to storage of SSN. Pulling SSN out of > systems with legitimate needs to use that identifier really seems like overkill > to me. The HR, Finance and Student systems are the data lifeblood of the institution, but even if their grade and payroll data doesn't flow to other systems, their identity data most certainly does. In 2007 we had been using data warehouses in relational databases for over 11 years. For much of that time, SSNs where the ONLY consistent identifier to hold the student and HR identity data together. We had SSNs in everything from Alumni to Parking and beyond. Our identity data was everywhere, still is. Except that now it doesn't contain SSNs and we're better for it. Those who have a business need to see SSNs can still do so, but they've got to make a conscious effort. The numbers don't just show automatically on anyone's screens and all access is audited. We do batch conversions for file transfers to the IRS, insurance companies and financial aid. However, because the SSNs are gone from the primary systems, there is no way for an employee to run a "select * from all_students" and save 500K SSNs to a hard disk or their own shadow database. Nor is there a way to leak SSN data to one of the hundreds of department level systems or web sites that we know nothing about. Our risk profile is now MUCH smaller. > I would assume that SSNs given as a requirement for employment or for > financial aid would be more accurate than the 1/6 unreliable statistic stated The 1/6th number is almost entirely from financial aid and admissions records. Long before an SSN is "validated" by the Department of Education, it may go through one or more iterations because of transpositions or fat fingerings; it might be a sister or brother's or mom's or dad's SSN. Since we're required by law to keep a copy of every SSN sent to us for purposes of financial aid, we end up with a lot of bad data. When we added our fin aid and admissions data to our SSN Vault, we grew by 1/6th. It is an unreliable stat, I grant that, but that's the only explanation I have for it. Every single employee, student, and applicant's "good" SSN was already in the vault when we added the financial aid and admissions data. Almost every one of these "bad" SSNs were not new people, but instead new numbers for people we already knew. The original poster asked: > So, we're curious whether IAM operations at other campuses have been > subject to pressure to remove SSNs, [...] and whether your operations have changed as >a result. The answer from the University of Missouri is: "Yes" we have seen a ton of pressure to remove them, and our processes have evolved to compensate. Though giving up our SSN addiction was tough, we're not really any worse off in terms of identity mismatches and we're safer for not having them around. Andrew McAllister University of Missouri >
I can see how the system you put in place could go a long way toward regaining trust and good will but I still wouldn't call it best practice to remove SSN from systems like HR. We were of course in the club (the use-SSN-for-identity-verification club), and we have moved away from that for all the reasons everyone else is or has abandoned the practice of pretending that SSN is an authenticator. What you describe I would call identity verification or authentication. I use 'Identity Matching' to refer to what some call 'The Join' or a behind the scenes automated process that attempts to recognize duplicates when updating a person registry from all systems of record (HR, Student System, etc). Because we populate SSN in our registry we are able to use our registry ID in place of SSN in the multitude of places that used to rely on SSN. Meanwhile SSN remains hidden and protected in the registry. In the end it looks like we have very similar policies regarding the handling of SSN. The only thing I think is not generally necessary is the extra level of abstraction where you have removed SSN from systems (like HR) that have legitimate need of it. The reasons you cite for doing so are good, we just chose to implement the controls directly in our systems of record and our registry.
Out of interest, what would places do that require SSN but that need to give accounts to international people that do not have an SSN?

R.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's education and research network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: 0xDE2F024C

On 13 Apr 2012, at 00:41, RL 'Bob' Morgan wrote:

I hate to start another SSN thread on this list (see Jan 2011 and Jan 2008), but I will try to constrain the topic.

UW is one of those sites that has a "person registry" driving its enterprise IdM, providing identities for accounts, authorization, etc. This UPR gets the usual feeds from source systems (HR, student, alum, extension, partners) and as one of its jobs tries to match person data coming from the different sources.  In our case one of the main items we match on is SSN; we get SSNs from the student and HR sources.

UW, probably years behind other campuses, is moving toward having a comprehensive enterprise SSN-handling policy.  This new doc sets out the acceptable situations for obtaining and using SSNs, driven primarily by federal and state law and regulation.  Processes like hiring and student financial aid require SSN, by law, so are explictly permitted.  Identity management matching is not required, so is a point of contention.  Our IAM team is seeking explicit permission for our long-standing practice.  Some other policy-drafting participants are pushing back, saying that SSNs can only be used for this purpose if individuals give their permission (ie, opt-in).  (It is notable that use of SSN for matching student applicant records between institutions is another non-mandated practice that is seeking, or may already have, this exemption.)

So, we're curious whether IAM operations at other campuses have been subject to pressure to remove SSNs, or obtain user permission to use them (which seems hopeless to me), and whether your operations have changed as a result.  We're not asking, today, about alternative matching approaches, or ways of protecting SSNs (but of course discussion will go where it will).

Thanks,

- RL "Bob" Morgan
  UW-IT IAM

Back in the days when we used SSN for student ID, we issued "fake SSNs" beginning with "888" to our international students.  If and when they were issued a USA SSN, we would change their record.  That may still be happening in the well-hidden and little used SSN field in our ERP.


Bob Bayn              (435)797-2396           IT Security Team
Office of Information Technology,     Utah State University
    three common hazardous email scams to watch out for:
     1) "phishing" for your email password
     2) unfamiliar transaction report from familiar business
     3) attachment with no explanation in the message body

I advise using SSN in Person Registry identity matching logic only if you already have the SSN.  It should not be required for identity matching.

 

Message from green@umdnj.edu

For guest accounts, we generate an internally tracked pseudo SSN. which can't be used for anything else.  For employees, I believe HR generates an 800-series SSN, which almost always causes problems down the road (like, when it gets assigned to someone else).

c
--

On 5/1/2012 11:46 AM, Rhys Smith wrote:
Out of interest, what would places do that require SSN but that need to give accounts to international people that do not have an SSN?

R.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's education and research network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: 0xDE2F024C

On 13 Apr 2012, at 00:41, RL 'Bob' Morgan wrote:

I hate to start another SSN thread on this list (see Jan 2011 and Jan 2008), but I will try to constrain the topic.

UW is one of those sites that has a "person registry" driving its enterprise IdM, providing identities for accounts, authorization, etc. This UPR gets the usual feeds from source systems (HR, student, alum, extension, partners) and as one of its jobs tries to match person data coming from the different sources.  In our case one of the main items we match on is SSN; we get SSNs from the student and HR sources.

UW, probably years behind other campuses, is moving toward having a comprehensive enterprise SSN-handling policy.  This new doc sets out the acceptable situations for obtaining and using SSNs, driven primarily by federal and state law and regulation.  Processes like hiring and student financial aid require SSN, by law, so are explictly permitted.  Identity management matching is not required, so is a point of contention.  Our IAM team is seeking explicit permission for our long-standing practice.  Some other policy-drafting participants are pushing back, saying that SSNs can only be used for this purpose if individuals give their permission (ie, opt-in).  (It is notable that use of SSN for matching student applicant records between institutions is another non-mandated practice that is seeking, or may already have, this exemption.)

So, we're curious whether IAM operations at other campuses have been subject to pressure to remove SSNs, or obtain user permission to use them (which seems hopeless to me), and whether your operations have changed as a result.  We're not asking, today, about alternative matching approaches, or ways of protecting SSNs (but of course discussion will go where it will).

Thanks,

- RL "Bob" Morgan
  UW-IT IAM



-- Cliff Green Senior Technologist Business Solutions - UMDNJ tel: 732-235-5250 fax: 732-743-3346

If you are having to create fake SSNs there is a good chance you are using SSN for something you shouldn’t.  Any business process that truly needs SSN will need a real SSN.

 

Message from green@umdnj.edu

In our case, it's strictly for generating a temporary account.  No other business process.  Anything further and they need a real SSN.


On 5/1/2012 12:35 PM, Jones, Mark B wrote:

If you are having to create fake SSNs there is a good chance you are using SSN for something you shouldn’t.  Any business process that truly needs SSN will need a real SSN.

 

Why is SSN required for generating accounts?  My experience has been that it is better to leave an SSN field blank or null than to populate it with something fake or temporary.

 

Message from green@umdnj.edu

Again, please keep in mind these are guest accounts.  We still use SSNs for disambiguation (to try to forestall creating multiple IDs for an individual).  To that extent, we still require an SSN (until we have either another, comparable, external datum or permission to not care so much about resolving identity conflicts and not creating multiple IDs for individuals).  We don't use it for any other IDM action.  Also, note that these are not in our ERP (Banner) but are in our people registry.

How do you keep track of IDs so you don't create multiples?

On 5/1/2012 12:52 PM, Jones, Mark B wrote:

Why is SSN required for generating accounts?  My experience has been that it is better to leave an SSN field blank or null than to populate it with something fake or temporary.

 

If we have SSN (like for employees, residents, and some students) we check for matching SSN as one criteria for deciding if an identity already exists in our registry.  For ‘guests’ (which for us means you are not an employee, student, or resident) the only criteria we use is name and birth information.

 

Our experience specific to our ‘guest’ population has been that the number of false positives, false negatives, and ambiguous matches is acceptable using that limited matching criteria.  For guests we collect, and may also match on, driver license number and/or passport.

 

In my opinion fake SSNs are not useful for disambiguation and actually cause problems when applications consume them.

 

Message from green@umdnj.edu

Granted, fake SSNs are worthless for disambiguation.  Fortunately, we haven't run into the need yet and it's more of a place-filler; so far, none of the guests we've done that for have become employees or registered as students. At that point, I suppose we'd have to update the guest's data to maintain continuity.

For guests, we ask for the full data (i.e., full SSN) if the guest needs more access;  we have a "low-assurance" level where only limited Active Directory access is granted if we can only get the last 4 chars of the SSN.  This is typically for vendors or consultants.

Unfortunately, I'd have to say we're somewhere in between not having any method for dealing with sponsored accounts and having a method with fewer warts and problems.  And, much as we try to avoid creating extra IDs, it still happens, e.g., when entries through HR or the Registrar don't quite match.


On 5/1/2012 5:04 PM, Jones, Mark B wrote:

If we have SSN (like for employees, residents, and some students) we check for matching SSN as one criteria for deciding if an identity already exists in our registry.  For ‘guests’ (which for us means you are not an employee, student, or resident) the only criteria we use is name and birth information.

 

Our experience specific to our ‘guest’ population has been that the number of false positives, false negatives, and ambiguous matches is acceptable using that limited matching criteria.  For guests we collect, and may also match on, driver license number and/or passport.

 

In my opinion fake SSNs are not useful for disambiguation and actually cause problems when applications consume them.

 

Message from mcallister@missouri.edu

> From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Cliff Green snip > For guest accounts, we generate an internally tracked pseudo SSN. which > can't be used for anything else. For employees, I believe HR generates an > 800-series SSN, which almost always causes problems down the road (like, > when it gets assigned to someone else). Since June 25th, 2011, the Social Security Administration has been issuing SSNs in random order out of the pool of remaining numbers, including numbers that begin with 8xx-xx-xxxx. Your fake SSNs in that range are going to start colliding with, or become harder to distinguish from, real numbers at some point. For larger institutions with significant foreign student enrollment this will start being a problem very soon. Why? Foreign students would have typically been given a fake number anyway, and they are also the most likely to have received a random number after 25-JUN-2011. Because several hundred million SSNs have already been issued starting with digits 0-7, newly issued "random" numbers have a greater than 1-in-9 chance of starting with an 8. Andrew McAllister University of Missouri
I guess I started the discussion about random fake SSNs for international students when I mentioned that we did that back in SSN-as-studentID days and surmised that we might still do that for SSN-as-SSNonly. I have learned that in fact we do not continue to "issue" fake random SSNs to international students. They all have the same 999-99-9999 number which federal agencies apparently recognize as the affirmative indication of "no SSN issued". We do NOT use the SSN data field from our ERP in our IDM system. Bob Bayn (435)797-2396 IT Security Team Office of Information Technology, Utah State University ________________________________________

No matter what your rule set is for your matching process you will have false positives, false negatives, and ambiguous matches.  The goal is to minimize these, not to eliminate them.  I wouldn’t worry much about duplicates (false negatives) as these are fairly easy to fix once identified.  What will really cause you headaches are the false positive matches.

 

Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.