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:
- First a given user name has to be correlated with a real person.
- 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:
component1+component2+password:method:checksum
The components are defined as follows:
Component1/component2
One or two protocol specifiers like http or mailto. At least one such component must be present. More are possible.
One of the components should be a http or https component, since this is the easiest way to fetch the required web resource. It is possible to fetch such a resource by just using a mailto component. But then the deliverd file probably would be an e-mail, not a (x)html file.
One possibility of an optional component would be user, which integrates the user name into the ID.
The format specification for an ID in an e-mail is still to be done.
It is possible though not recommended to use a large number of components. One of the problems that arise here is that a service trying to identify a user has to make some assumptions about necessary information building the components. Although it would be possible to ask the user for missing information in an extra form, this is extra work. So the standard components should be an http or https component and a mailto component. These are the two information pieces mostly used today anyway.
password
Just the string "password".
Method
The encryprion method. Usual methods are sha1 or md5. Others like blowfish are possible.
GPG
By using GPG as method, in both cases, at creating as well as verifying the ID, the public key must be used. There will be no decryption!
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 "mailto:siegfried@rorkvell.de" | sha1sum | cut -d' ' -f1`
HTTP=`echo "http://www.rorkvell.de/" | 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\" />"
Publishing
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.
Indirection
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="https://www.rorkvell.de/priv/auth" /
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.
Authentification
Scenario
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
-
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.
- 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.
- 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.
- 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 "+".
- 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.
- For creating the hash the method named in the second field is used.
- 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.
- 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.
Summary
- This method is not meant to replace authentication via user name and password.
- This method avoids any registration and storage of maybe sensitive user data at any third party servers. Every usre owns his own user data, holds his own user data on his own web space, completely controls it hiself and is completely self responsible for them.
- Web pages may be hacked. This enables the hacker to alter such IDs. This would be of limited use for the hacker, since it affects only one user. Only one user would so be prevented from legally commenting and may be victim of identity theft. Any other users of that service are unaffected by this.
- This method does not need any service provider. No third party is involved. Any user controls his/her own user data. No registration, no storage of any user data.
More ideas
These ideas are just meant as ideas and are not part of the specification:
- It would be possible to search for more user data. For example data in microformats hCard format, or with RDFa and for example vCard or FOAF.
- Or there may be a link (rel="me" to a page containing such additional data.
- Such user data for example may specify an avatar to be used. This may then be linked directly. Regardless of wether this avatar is a Gravatar, a Pavatar or simply an image hosted at the users web space.
- The page may contain a link to the users blog. This enables adding a link to the commentors blog in his comment.
