Id

Problem Definition

The problem of authentication can be simply stated as, "Are you the guy I was talking to earlier?"

Computer programs and systems and databases require that people using the systems identify themselves. Whether or not a particular person can do something is a question of authorization. There is no per-user authorization without authentication.

Usually, authentication systems go above and beyond what is truly necessary.

This Id system is intended to be a truly simple, truly easy-to-use system that can be adapted to any scenario or system.

Overview

Users create an account on an Id server. It doesn't matter which one. It doesn't matter how they identify themselves. Ideally, it is a simple user-password combination, although it need not be.

Once the users identify themselves, they have successfully authenticated against their own Id server. Now, this is truly useless except for the fact that using this authentication, they can authenticate to other servers who do not keep track of *how* the users authenticate with the first.

The second servers have two questions: (1) What is your proclaimed Id? And (2) How do I know you actually own that identity?

The answer to (1) and (2) need to be some sort of shared secret. (1) is a publicly visible User ID. (2) is a secret that can only be shared with the originating authentication server the user claims an ID on.

The User ID is a simple "user@domain" pattern. The user@domain must be unique. Two different users can't share it.

A user can choose to create an arbitrary number of personas through a single ID server. They need not share their original ID with 3rd party servers.

Example: I am jgardner@jonathangardner.net, but when I log into some.other.domain.net, I tell them I am "fubar@jonathangardner.net". I never tell them I am jgardner@jonathangardner.net.

The advantage of this is that now 3rd Part servers can't collude and compile information among them. You are a different person to each server.

There is never a case where two different domains need to have the same ID. Even in the case of financial transactions, all that needs to happen is that a particular amount be transferred to the ID. 3rd Party websites can ask that the user fund yet a different ID to fund the ID which was provided. Example: I, jgardner@jonathangardner.net, go to some.other.domain.net to buy something. There, I am fubar@jonathangardner.net. They ask me to pay, so I go to my.bank.com as bobaz@jonathangardner.net and ask them to pay the invoice identified. The bank merely tells some.other.domain.net that funds are available for the invoice, and need not identify who paid.

In this way, almost complete anonymity can be maintained.

Authentication Process

You need to provide a unique user Id to your ID server to login with. How you authenticate and login is not described. For example, a simple email-password system suffices. If they forget their password, they can request an email be sent with a reset link. However, more inventive methods can be used, depending on the level of security desired.

When you go to login to another site, it requests a user ID and a password. A user ID is generated with random numbers and letters. A one time password is also generated. This is immediately passed to the site, which forwards it to the service to verify the one time password. If it is correct, then the session is authenticated as that user.

The above process should happen opaquely to the user. The HTTP request may issue a 401 with a header indicating that this authentication style is accepted. Then, when the user ID and password are supplied, it can verify it.

Which server to authenticate against, and what API? That is up to the domain name of the User ID. A DNS check is made looking for a TXT record that identifies the URL to use. There, the 3rd Party server passes the User ID and password to verify. A positive response indicates success. A negative indicates failure.

SSL

Of course, it is suggested to use SSL for every transaction, but this need not be the case. Since each site gets a unique and different User ID, if the connection is jeopardized then only that site suffers the consequences.

Personal Information

With this system, it is not necessary to supply any real-world personal information. Every service from snail mail to phone calls can lie behind an anonymized random ID. Each site can be given a different set of information.

As an example, let's suppose you want to be sent a package. A service could be offered that accepts package deliveries. Depending on the code on the package, it is forwarded to the right person.

Simplicity

This system is simple enough that it can be easily implemented.

3rd party websites no longer need to manage passwords or user accounts with personal information. They simply used the consistent and unique user ID. Every login is authenticated against a different website. If the password is wrong, they simply deny access. The user can simply generate a new password and try again later.

For each site, you create semi-random user IDs.