At 05:37 PM 8/24/99 +0200, A.R. (Tom) Peters wrote:
> 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?
I have to go along with this one. Let's have a flag that the user can set
to be included or not in any searches.
> The other major issue is, what do we use as a unique personal
>identifier? There are several options:
I have always liked the idea of using an email address as the unique
identifier, since that *has* to be unique, no? Now, there *will*/should be
an internally generated unique id for indexing purposes, etc., but that
remains internal to the database.
Using the email address for the unique identifier takes care of a lot of
problems. If they change email addresses, it still needs to be unique
(which will help the users find the record) and the internal id will still
remain the same.
>(* 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?
> Or do we require active participation by the candidate, who would need
>to disclose his semi-secrte ID ?
> The answer to this question determines the type of ID we can use.
The candidate should be able to give the employer his unique id (Read:
email address) for purposes of searching our database.
>(* 2b *)
> Do we require the name as part of the input data for the
>certification-verification service ? (if a valid answer is returned, the
>name matched the rest of the ID); it is easy to make errors in names
>however.
If we use a unique identifier that is not (necessarily) secret, I don't see
a problem here.
________________________________________________________________________
This message was sent by the linux-cert mailing list. To unsubscribe:
echo unsubscribe | mail -s '' [EMAIL PROTECTED]
