I actually started thinking about this sort of thing about a week or two ago and a post on the
Maryland Shooter's Forum about the proposed Real ID and RFID
guidelines brought it up again.
I was thinking of keeping this hush and actually developing a system for this and obtaining relevant patents. However, searching through patents and the whole application process can be rather costly and consuming, not to mention the difficulties in enforcing patents. Besides, I tend to agree with the philosophies of Open Source Software and Creative Commons licensing of works. There's some discussion on this over at the
instructables.com forums that covers this topic as it relates to patentable works. So since I've posted my idea to the MD Shooter's forum, I figure I'll also post it here with some more details.
Based on my brief research I have concluded that this is overall an original idea, though pieces, or general concepts, may have been previously proposed. So, if this idea, in whole or in part, is stolen and shows up on the market before I get around to fully developing it and selling/marketing it myself, I expect to be credited, consulted and receive fair compensation. I still have the opportunity to apply for patents and if anyone sees any of this in a patent application let me know.

In the recent past I had an idea that I believe very well may have been stolen from me which I'll get into another time.
On with the show...
Some of this is related to security/privacy policy which I think should be implemented regardless, but the system would require it.
All databases are to be devoid of personal identifying information.
There may be certain exceptions to this based on reasonably justified need, but any personal ID information should be kept out of all database systems to the greatest extent possible such that it cannot be used for things such as ID theft or other nefarious purposes. This would make the data relatively useless if compromised by crackers or to any unscrupulous employee or other person that normally is allowed access to the data.
I'll go off on a little side tangent here and throw in that SSN's should only be found in databases at the SSA, they don't belong anywhere else (well the IRS hijacked SSN's as TIN's but that's another story),
they make bad database keys, and are completely useless and unreliable for identification purposes (it even says so right on the card). I'll leave my arguments and opinions on why SS shouldn't exist at all for another time. The misuse of SSN's by companies and, probably to a lesser extent due to pertinent laws, government agencies has become so common that now it's finally being realized how vulnerable to abuse this practice is. For too many reasons, an SSN cannot be trusted for verifying or authenticating a person's ID.
In place of this should be something like a PGP public key. The only way to get the personal info is directly from the individual. An alternative is to encrypt the stored data with the public PGP key, but this could make for some messy and/or more resource intensive database systems.
The individual whose personal information is stored controls their own personal ID information and decides who can access what pieces of it.
How it Works
The system requests the info from say an RFID chip (I'm not sure these would really be suitable for this application, but possibly as RFIDsec has come up with secure RFID devices with privacy features which I haven't fully looked into).
My first thoughts were of something like a USB memory stick, such as the
SecureStix, (
but not a Sony product) with a fingerprint reader to represent the passphrase for the private key, though something a little more sophisticated may be necessary.
Anyway, the request is encrypted with the public key on file and signed with the requester's key, the individual accepts the request with their passphrase (fingerprint?) and the allowed data for that particular requester is provided to them encrypted with their public key and signed by the individual's key. The pertinent data shows up on the requester's screen but does not get stored in any way. This could still potentially be abused, I haven't thought through all of the details far enough yet, but the system would work something like this. Maybe some reliable auditing certification could be part of ensuring that the ID data is secure, but it should be possible to do this within the program. It would have to verify that the OS isn't compromised in such a way as to allow for grabbing the data as it's routed from post-decryption to the video display. Hmmm... there's of course other issues as well.
Trust of the ID
As long as the individual's key is signed by some acceptable authority it is considered to be trusted valid information (ie. the person is who they say they are), no need to worry about what two or three forms of ID are acceptable for which entity that requires ID because the ID info for that key has already been verified either by that entity itself or a valid third party (eg. the local courthouse, state police, State Dept., etc.). Additionally, the key/passphrase info is
almost impossible to forge and the primary ID (ie. name) is tied to the PGP key and cannot be changed. Some good info on PGP and the web of trust theory, which I haven't bothered to get into, can be found at
David Ross's site and of course at
GNUPG and PGP.com.
There are still some points that need a little work in this idea, and the .gov would probably never adopt such a system fully without it's own exceptions (there's still too many control-freak--nanny-state--power-trip politicians in office), but with wide usage it could certainly cut down, or eliminate for the most part, ID theft, and many other crimes which are facilitated by the improper use of personal data. Plus maybe it could restore some sense of privacy and security in a world where there isn't much left without removing oneself from at least most of civilization and technology.
Maybe I've watched "The Net," "Enemy of The State," and similar movies too many times, or maybe I've just been involved in computer networking and security too long.