[Auth]Virtual Identity proposal

[Mark Saward]

The following is an idea of virtual identities that I have.  Feel free
to ignore it, suggest for it, criticise it, feed it to your dog, or use
it.

---------------------------------------


Virtual Identities:

Concept:  A method by which computer users may personalise/customise
their internet experience, while containing personal data locally,
giving the user full control over how the information is revealed.

The problem:  The problem is twofold.  The first is to provide
competition to end the elimination of Microsoft's attempts to dominate
and control the internet.  The second is to ease the use of the internet
by customising and automating some of the experience of a user on the
internet.

Method:  On a computer the user would have installed a certain program.
We will call this the virtual identity server (vis).  This server would
be configured and maintained by the end user.  It would contain various
fields of information, such as name, address, phone number, operating
system.  There would also be lists tied to a domain name.  The lists for
each domain name could contain the fields that are available for that
site to request, and various permissions:

~/.vis/domains
---------------------------------------
# sampleonlinestore.com vis permissions
global
alias           allow

site            sampleonlinestore.com
service         web             //An identifier to recognise a specific         
                        //service on a
domain
firstname       allow
lastname        allow
address         ask
creditno        encrypt,ask
key             encrypt
---------------------------------------

Explanation:  
Line 2 defines global settings.
"alias          allow" means that any service may request the alias field and
retrieve the information without problems.
Line 5 (site sampleonlinestore.com) is the domain name for the following
list of settings.  
Line 6 (service) defines which service these options are for.  There may
only be one service of each name at any particular domain.  The service
name is decided by the service itself, and can be an arbitrary name.
When defining settings, this service name must be known - but this won't
be difficult to find out.  Standards will arise, so an educated guess
can be made (eg port 110 is usually POP).  Also, the vis may allow for
automatic entry into settings when a service is first visited, more
below.  It may be decided that service name will be the port number, but
then this does not allow for services that change ports each time they
are run.  Also, a name allows a service on a particular page to change
over time.  Eg, a site may revamp it's webpage or accidently lose all
previous records.  In this case it could change its name to "web1" to
count as a new service.
The rest of the lines are a list of fields of information and the
permission the site has regarding requesting and obtaining them.  In
this example this particular service may request firstname and receive
it without interruption.  Ask means that the vis will ask for permission
first.  Encrypt means that it allows the information, but sends it
encrypted.



Security:
Each vis would, on first installation, generate a virtual identity key
(vik) a large enough size so that no two vis' will generate the same
vik.
This method can be used when security is desired (such as sites that
remember a visitor and confidential data).  The vis or the service may
reqeuest a key.  If the vis allows it (such as in the example above
allows it encrypted with 'encrypt'), then the vis and service each
generate a key.  They then exchange keys, and store their generated key
in association with the other's generated key.  The vis would store the
vis key and the server's key together under the appropriate domain and
service.  The service will record the vis' key with it's own key, along
with the vik.  The vik allows the service to quickly discover which vis
in it's history is trying to authorize itself.

Example of security process:
User connects to the service webpage at sampleonlinestore.com  This
store sells computer hardware.  The user goes to set up an account on
the webpage, so the vis automatically adds the domain (if not already
present) along with the service name that the webpage calls itself by
(the user could have set it up so the vis requested permission before
adding any new services to the configuration).  The default setting for
the service is secure access, so it requests for a key.  The vis
generates a key and records it in association with that service and
domain name.  It then sends the key encrypted to the service.  The
service then generates a key of it's own, records it in association with
the user's vik and the key the vis just generated.  The service then
sends it's key to the vis.  The vis stores it in association with the
domain name, and service, along with the key.  From then on, any new
connection is verified by the comparison of keys.

Example:
This would allow Joe Bloggs to connect to www.sampleonlinestore.com and
automatically and securely enter the data required.  When visiting the
site for the first time, Joe Bloggs clicks on "new user".  He then
receives a popup for the new site asking for permission settings.  Mr.
Bloggs selectes "credit" which is the name he gave to a custom
configuration giving full details including credit card no.  The site
then automatically goes to a custom start page for his new user,
allowing him to customise it, purchase items, etc.  All Mr. Bloggs
needed to do was click the button "New User" then "credit" and it was
all set up for this trusted site.  Each user may define their own
security settings, so another paranoid user may use more restrictive
settings that asks permission before sending information like a credit
card every time.

Advantages:
* Allows secure revealing of information over internet automatically.
To facilitate easy setup for a trusted site, Joe could enter a generic
permissions section.  When the vis adds a new service/domain to
it'sconfiguration, it could request Joe what default permissions to use.

Problem:

* A user who switches computers frequently will have problems with
different vis setups/inquisitive admin

Solution 1: have the ability to store settings, etc, on a server that
can be retrieved by the vis with a password
Solution 2: be able to encrypt files and copy them from computer to
computer, unlocking them with a password.  To encrypt it have all the
necessary files stored into a single file, which is then compressed and
encrypted.  This file could allow easy use of multiple users on single
user systems (such as win95/win98).  *nix users will not need to worry,
unless they are worried about administrators.

Copywrite under the GNU Free Documenation License
(http://www.gnu.org/copyleft/fdl.html) by Mark Saward