Class (or parent) UID

It would be nice if there was a way of testing is an object "one of these". So for example if I make a door that opens depending if someone is holding a special key, I could copy the key and give one to who I like, and a test could be made by the door to see if someone was holding a copy of that particular object.

This can be done with scripts.
The door, when clicked does a llSay() on a private channel, then the key hears it and replies back on another channel

So the key says "yes I am one of..."?

But that's not very secure, since anyone can then create a doorkey simply by scripting it to say yes to that question. Whereas if I have made the parent key and make the child keys non-copyable, then no one can reproduce another object with that UID.

Well, it depend on how you encrypted the conversation. My 'server' also use the key method Draco18s said, but in much more complicated than just asking 'Are you the key?' and 'Yes' as the response.

The channel can be randomly generated by the door's UUID or the UUID of the one who try to open. The key's response can be done via e-mail. The conversation can be encrypted with secret code known only to the Key Maker. Not as safe as the standard SSL encryption, but it will be hard enough for people to not try to replicate the key. (well since they'd probably just Sit-tp into it instead) ;p

Now that you talk about it, maybe I could just start a Key Maker business "Nargus the Key Maker" =P

What Nargus said (I've seen the code he uses).
You can't just "create" a key to say "yes."
First you have to know the channel (there's over 2 billion channels (the debug channel is 2,147,483,647)).
Second you have to know the message--which can be encrypted. If it is, it's entirely possible for the encryption to be the UUID of the keyholder (or a derivitive), which means even if you sniff the message of someone else (see #1) then your message won't be the same.

Parent UUID's would be nice not just for this, but more importantly knowing instantly WHAT rezzed you. ie - a parent rezzes a child object, the parent knows the child object's key via the object_rez() event, but the child object only gets an integer via on_rez(). If objects tracked parent UUID then the child would be able to know what created it and use this information to do things such as use sensors to see if the parent object still exists/is within range.

It would also allow for some more advanced self-replicating object traps, since self-replicating objects would leave an extremely 'tall' hierarchical chain of objects it is descended from, all of which would still be present in the simulator. This could even be of use to some scripted applications as well.

It's unfortunate that we currently lack an ability to communicate directly with an object whose key we know (as with a form of instant messaging) as parent UUIDs would then allow for much more secure communication, an issue which this thread has already raised

I'll agree there is use, but not exactly in the way that the OP said. As if the door rezzes the key which is then Taken, it will lose that parent/child relationship.

Maybe the key can then remember which parent UUID it is. So it can only be used with that parent without a need to config? ^^

That would mean anyone can code an object to declare itself a child of that object. It really does need to be in non-writable storage.

Um...I still not understand what you meant actually. The door's UUID would be kept merely for channel and message encryption. The actual encryption method can be obscured. For example, you put put together door's UUID, key's UUID, random secret text, date, and sim name together and use that as a secret password. That way, even if someone else can sniffed the channel number, they can never reproduce the correct answer to the question. Since the answer must be encryption with dynamic password unknown, which is changed everytime a new key is rezzed. And it is not easy to sniffed out how to regenerate a password, unless you are the creator, or a hacker.

Hmm, good point as rezzing from inventory would have to set the parent to your UUID (as you just created it).
Actually, the proposal on the Jira would be more useful for this particular application, namely; llGetCreatorKey(). This would allow a key to test to see if it was created by the same person as created the doors, that is if you only want this system for yourself. That way you can give someone the key and they can now open any of your compatible doors.

llGetCreator() key would work, assuming the owner creates the doors and the keys and only has one set.

Meaning you'd never be able to sell the system.
And
You'd never be able to have two buildings accessible by two different groups of people.