Secure Identity
(Project Proposal)

Jeff Cobb

2 April 2022

Download a printable PDF version.


This is an incomplete product idea. As such, it has a limited feature set and requires discussion from both a technical and a `marketability' perspective to be considered a feasible project. If I am unclear in parts of this, I must apologise; this is the most that I have written about this idea and therefore may not necessarily explain it in the most logical manner possible. Please read the whole proposal before killing the idea or asking questions.

The problem to be solved

Currently, to make purchases online or even to send your email address to a company or institution, one must implicitly trust not only the communication medium (usually SSL under the best of circumstances) but the institution or company as well. Unfortunately, in this era of EULAs or AUL agreements, a company can tell you that it will not share your data with anyone else and a month later, rewrite the agreement to allow them to sell your data to whomever they please, which leads to the next problem: managing SPAM (unsolicited email). Once you start receiving the SPAM, you are never sure how they got your email address and do not (or cannot) trust the `opt-out' link invariably at the bottom of the email message. Short of complaining to the spammer's ISP, there is nothing that you can do, and the spammers know this.

One possible solution

Currently, the way that PGP works (for those who are unfamiliar with PGP) is that you can create a message destined for one specific person and (providing that you and the other person has exchanged public keys) and through the magic of public key encryption, be sure that only that person will be able to decrypt it. In the event that you feel that your personal key has been compromised, you can `revoke' that key and simply create another key. Because keys can and do change (for whatever reason), public key servers exist where you can publicly revoke your old key rendering it useless and publish a new one.

What I am proposing is a bit of a twist on that logic. It would start with a client which uses the same basic methods as PGP for key management but rather than it encrypting messages, it would simply encrypt some or all of its internal data. This data will represent your personal identity to the Internet. It would feature varying levels of information, ranging from a simple email address to (on a higher level) credit card information. The trick in this case is to also embed a recipient ID in the data (in the case of an email address) or some other part of the system. The purpose of the embedded information is to allow you to perform an audit of sorts so that if company A sells your address to company B and then company B spams you, you can (through a feature of the client) trace it back to company A. The exact nature of how this embedding process works is one (of many) points for technical discussion. To carry this aspect of it a little further, you could also set timeouts ( or usage counts) on the data sent to company A (say you are simply requesting some information from company A about a product or whatever) so that company A cannot use that data beyond a certain date, number of days or number of decryptions. Since the ID of the recipient of that data is embedded within the data itself in some fashion, you can always tell when company A is doing something fishy with it.

Finally, the data will only be accessible via the use of a third key that can only be gotten from a public `identity' server. If company A either does something with your info that you are not comfortable with or worse, if they are hacked and they have your credit card number, you have the right and power to revoke company A's access to your information. This strikes me as a lot easier than what most people do (in the case of spam) which is to maintain a number of email accounts or change addresses. The end result is that you the individual, are in control of your personal information again. Rather than opting out of an e-mailers spam (which usually simply confirms that the address is valid and so will send you even more spam), you can remove your address from their availability. In terms of e-commerce, you would be able to send your credit card information over an unsecured (because you are providing the security) line. Without all three pieces of the puzzle (your key, the recipients key and the third key at the authorisation server), crackers have little to work with. For that matter, if things are done properly on the business end, there would be no more credit card numbers stored on web-sites, thus further reducing the lure of certain types of sites to crackers.

This is simply a brief outline of an idea, one that I think could be big if the right minds are behind it. Honest retailers and people should embrace such an idea because it can only help their reputations as a secure place to shop, in effect making online shopping safer than going to a local store. Spammers of course will hate it but then IMHO, it is time that spammers got a taste of their own medicine (as in not being in control of the situation as they are now).

Points of discussion

Obviously there are some technical hurdles to be solved before this is possible. Certain bits of infrastructure need to be added/changed before we can bring all of the features online. On the client side, it has got to be the simplest piece of software in terms of usage so that Joe Six-pack will use it. The trick with the embedding of ID info into data could probably be managed with a special public mail server that could translate the special addresses into your real personal address and automatically insert the ID data into the message. In a strange way, it would be like a firewall for email, only much more. If done this way, you could use any email client to access your email and (via the cross-platform client) know who sold your data (if they did) and if you as the individual so choose, revoke the address. To really carry this further (and this is more of the infrastructure I spoke of ), agreements could be made with major credit card companies so that when you make a purchase, you (as the user) send company XYZ your authorisation to use credit card X (which they never see the number of) for a $20.00 item (the currency doesn't matter); they then further authorise the purchase by going to a public server which would confirm that it was you who sent the request. Through a server-side application, this then creates a unique piece of data that is then sent to the credit card company (VISA) which then (via prior agreement with you) uses your key to actually approve the purchase. The net result is that your credit card information exists in exactly two places (besides the credit card itself): In encrypted form on your hard drive and at the credit card company itself.

Well, I said there are points of discussion and then seemed to try to discuss it all myself. What are your thoughts? I am more interested in ways of making this work than reasons that it won't. There are no problems, only opportunities, as a mentor of mine was fond of saying:

Let's see what opportunities we can make for ourselves....

Jeff Cobb
<[email protected]>

HTML generated using LaTeX2HTML
by Ross Moore, 2022-04-03 for FD-IT