Secure Identity
(Project Proposal)
Jeff Cobb
2 April 2022
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.
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.
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).
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