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]
