Gabriel Krabbe
Tue, 24 Aug 1999 11:27:11 -0700
On Tuesday, August 24, 1999, A.R. (Tom) Peters wrote: > LPI will be maintaining a database with information on people who took > one or more exams. [...] > (* 1 *) > Do we make it a policy that for all people who took one or more > exams, the certification status can be polled anyway ? (i.e., we won't > tell that he failed the L.II exams 5 times, but just that he has an LPIC-1 > certification since date so-and-so). > Or do we make it a policy not to disclose this information unless the > candidate made explicit that he wants to participate in this service? Assuming a written, signed and sealed certificate will be provided upon success, the latter gets my vote. The database should (will, I hope) contain him anyway, along with some sort of unique ID (I suggest self-generated, anything else has less benefit than hassle) also carried on the certificate. Thus, if anyone changes his mind, he can notify whoever at the LPI and have them change the "public query allowed" flag appropriately. > The other major issue is, what do we use as a unique personal > identifier? There are several options: > > A) full names > + personal > - probably not unique > - variant spelling Hassle due to the uniqueness problem. The variant spelling can be ignored and/or worked around, but I wouldn't want a publically queried database to list me as "GK1688" - that's ok for the internic to do, but I don't want to be a number to a future employer. Coming to think of it, "GK1688" is an acceptable ID, as opposed to "Gabriel Krabbe 2", for purely philosophical reasons. > B) social security code > + personal and unambiguous, but: > - different format in different countries > - maybe not unique (the same number for different persons in different > countries) > - illegal to use by a non-government agency in some countries (e.g. > Canada) Doesn't exist in a comparable manner in Germany, for one thing. Having a "Sozialversicherung" isn't compulsory in all cases, one of these cases being people who are between jobs, so to speak. Leaving that insurance when no longer required to be in it and rejoining later when I am again will mean a change in number for me, and possibly assignment of the number I once had to someone else. In other words, this is probably the worst choice of all, as the single advantage it could have doesn't actually exist. > C) generated unique ID (number) > + unique, unambiguous > - semi-secret (what is the ID of a certain person?) > - not personal: people may claim an ID that isn't theirs but they know > it has a high level of certification; how can an outsider check the fraud? > - easy to poll for the certification status of all candidates (by > polling all possible ID's) instead of just an individual. See below for the latter point. IMAO, not only the best but also the only useable idea. Sort of like NIC-Handles: unique, but vaguely personal through the initials. [...] > (* 2a *) > Do we want the employer to be able to do that independent of the > candidate, i.e. he is able to guess or obtain the ID used in our database? While this isn't a bad thing, the only use would be to headhunters. I see no added benefit in a "list all" function, but I see no problem at all in guessable IDs. > Or do we require active participation by the candidate, who would need > to disclose his semi-secrte ID ? Same difference. If the IDs aren't completely random, they're guessable or listable. So what. If I have a certification, I shouldn't worry if people know that. If I don't hold a certain level, then I don't, and shouldn't worry if people know that - after all, and this is important, they do not know whether I failed to pass or failed to take it. Let me repeat: Nobody except the LPI, your examiner, and you (and possibly your current employer, who sent you to the test in the first place) can find out whether you failed or didn't take part. Only data that can in no conceivable way be negative to you, the certifyee (I need that word, hence it exists) is "leaked". > We want the prospective employer also to be able to verify that the > status actually belongs to that person, so a name should probably be used > in the procedure [...] > Or do we return the name with the certification status ? (so he can > check that the ID belonged to the candidate): this may be vulnerable to > breach of privacy. I see no breach of privacy whatsoever, see above. Summary: - Carry all certifyees in the database. - Give all certifyees a unique ID, my suggestion is NIC-Handle like (for convenience) - Include an "opt-in" flag for all certifyees whether they agree to be publically queriable. - Allow queries only by ID, return the name and the certification level on exact match (case insensitive). Gabe -- I love cats... they taste just like chicken. ________________________________________________________________________ This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]