User authentification - what is it? It is about identifying a user, who for example wants to publish something in a forum or cemment to a blog, and then authorize him accordingly.

A working authentification has to cope with mainly two tasks:

  1. First a given user name has to be correlated with a real person.
  2. Second it must be ensured that the person, which is f.ex. writing a comment, is the person he/she claims to be.

There are various approaches to do that. The most usual is a registration at the service side. The drawback is that the service provider necessarily has to store quite a bunch of user data. Regarding privacy and security this is a problem. Moreover there is only one person possible using a given user name. Several diffrent users using the same user name (nick) are not possible.

This proposal here does not only allow using services like forums and blogs and similar using whatever user name. It is also possible for various users using the same user name. And it completely avoids storing anything about the user at the service side. Every user holds his/her own user data on his/her own web space. Any third party storing is avoided.

The proposal here is based on the microid ideas and extends these by an important point. This concept here is not meant to replace the usual login procedure with user name and password. This procedure is completely kept as-is. Just the registration and the storing of user data is skipped.

More this proposal is not an alternative to openID. That copes with "single sign-on" (the possibility of logging into one site and then automatically beeing logged in on many other sites), while this proposal does not try a "single sign-on".

ID construction

Like microid an ID is built of two or more components. Different to microid there must be a password component. This password ensures that the person is indeed the one he/she is claiming to be. So the general format of an ID then is:


The components are defined as follows:

Ordering of the components does matter, but may be arbitrarily chosen by the ID owner. All these variants are valid:

component1+component2+password:method:checksum component1+password+component2:method:checksum password+component1+component2:method:checksum

User name (nickname)

The ID may be limited to (associated with) one user name. If this is not done, then the person could be identified only by the remaining component(s), f.ex. the URL.

Generating an ID

For example an ID may be generated this way (using bash script):

#!/bin/bash MAILTO=`echo "" | sha1sum | cut -d' ' -f1` HTTP=`echo "" | sha1sum | cut -d' ' -f1` PW=`echo "verysecret" | sha1sum | cut -d' ' -f1` ID=`echo "$MAILTO$HTTP$PW" | sha1sum | cut -d' ' -f1` echo "<meta name=\"myID:Siegfried\" content=\"mailto+http+password:sha1:$ID\" />"


The ID should be published on a web page. Assuming that only the owner of a web page can alter its content, this assures that the person with a given user name is indeed the owner of that page. Publishing should be done similar to microid:

meta name="myID" content="component1+component2+password+method:checksum / meta name="myID:Joker" content="component1+component2+password+method:checksum /

The first variant does not associate the ID with some specific user name. The second variant associates an ID with, in this case, the user name "Joker". There are as many such statements possible as needed, as long as the user names are distinct. An ID without a user name is a fallback ID for any other username of the owner of that web page.


It is possible to not hold the ID in the web resource given by the URL entered in the comment form, but instead point to that web resource there. For this the link element is used:

link rel="myID" href="" /

The advantage of such indirection is f.ex. to enter the URL to the home page or blog into the comment form, thus publishing that url there, but keeping the web resource containing the ID's at a central location. Additional this avoids the necessity to enter the URL containing the ID's in exactly the way it was entered during the ID build process. The URL containing the ID's must be present in the pointing file in exact that way.



Let's assume a person X with user name "you" wants to comment on a blog article. So besides entering the comment this person at least enters his/her user name "you" and a URL and a password.

Server actions

  1. The server first loads the web page given by the URL. Then it searches for any meta statements with the name "myID:you", and, if not found, just "myID".

    Rem: A format specification for other file format like RDF is still to be done.

  2. If an ID is not found, but a link to a web resource containing such an ID, then this web resource is loaded and then continued as above.
  3. If loading the web resource is not succesful due to password protection, then it may be tried to load it providing the entered user name and password. If this succeeds, then the ID in that web resource does not necessarily need to contain a password component. In this case the ID there might be a simple microid.
  4. If an ID was found, the build algorithm is extracted. This is the first field, separated by ":". The fields of the algorithm itself are separated by "+".
  5. For any component of user information of which its name is found in the build algorithm a hash is made. Then these has values are concatenated, keeping the order given in the algorithm, and then a hash of that concatenated string is built.
  6. For creating the hash the method named in the second field is used.
  7. If the calculated result is equal to the third field of the ID then the user is identified. Any authentication then may be done by local rules.
  8. The password entered by the user should be used just once and then not stored. The sever should immediately after user identification delete the password, regardless of successful or not successful identification.

Spam protection

Consequently using this method does not directly prevent spam, but since the user (spammer) is identifyable he/she may be billed.


More ideas

These ideas are just meant as ideas and are not part of the specification: