The usual approach to authentication online is the "login" approach -- you enter userid and password, and for some "session" your actions are authenticated. (Sometimes special actions require re-authentication, which is something my bank does on things like cash transfers.) This is so widespread that all browsers will now remember all your passwords for you, and systems like OpenID have arise to provide "universal sign on," though to only modest acceptance.

Another approach which security people have been trying to push for some time is authentication via digital signature and certificate. Your browser is able, at any time, to prove who you are, either for special events (including logins) or all the time. In theory these tools are present in browsers but they are barely used. Login has been popular because it always works, even if it has a lot of problems with how it's been implemented. In addition, for privacy reasons, it is important your browser not identify you all the time by default. You must decide you want to be identified to any given web site.

I wrote earlier about the desire for more casual athentication for things like casual comments on message boards, where creating an account is a burden and even use of a universal login can be a burden.

I believe an answer to some of the problems can come from developing a system of authenticated actions rather than always authenticating sessions. Creating a session (ie. login) can be just one of a range of authenticated actions, or AuthAct.

To do this, we would adapt HTML actions (such as submit buttons on forms) so that they could say, "This action requires the following authentication." This would tell the browser that if the user is going to click on the button, their action will be authenticated and probably provide some identity information. In turn, the button would be modified by the browser to make it clear that the action is authenticated.

An example might clarify things. Say you have a blog post like this with a comment form. Right now the button below you says "Post Comment." On many pages, you could not post a comment without logging in first, or, as on this site, you may have to fill other fields in to post the comment.

In this system, the web form would indicate that posting a comment is something that requires some level of authentication or identity. This might be an account on the site. It might be an account in a universal account system (like a single sign-on system). It might just be a request for identity.

Your browser would understand that, and change the button to say, "Post Comment (as BradT)." The button would be specially highlighted to show the action will be authenticated. There might be a selection box in the button, so you can pick different actions, such as posting with different identities or different styles of identification. Thus it might offer choices like "as BradT" or "anonymously" or "with pseudonym XXX" where that might be a unique pseudonym for the site in question.

Now you could think of this as meaning "Login as BradT, and then post the comment" but in fact it would be all one action, one press. In this case, if BradT is an account in a universal sign-on system, the site in question may never have seen that identity before, and won't, until you push the submit button. While the site could remember you with a cookie (unless you block that) or based on your IP for the next short while (which you can't block) the reality is there is no need for it to do that. All your actions on the site can be statelessly authenticated, with no change in your actions, but a bit of a change in what is displayed. Your browser could enforce this, by converting all cookies to session cookies if AuthAct is in use.

Note that the first time you use this method on a site, the box would say "Choose identity" and it would be necessary for you to click and get a menu of identities, even if you only have one. This is because a there are always tools that try to fake you out and make you press buttons without you knowing it, by taking control of the mouse or covering the buttons with graphics that skip out of the way -- there are many tricks. The first handover of identity requires explicit action. It is almost as big an event as creating an account, though not quite that significant.

You could also view the action as, "Use the account BradT, creating it if necessary, and under that name post the comment." So a single posting would establish your ID and use it, as though the site doesn't require userids at all. Of course, if the site does want login, this is just a special case. There is no need to enter in a userid and password, of course, but the login button would be changed, by the browser, to say, "Login as BradT" so it's clear to you what you are doing when you press it. In addition, the concept of login could be changed, so that rather than creating a session on the site, it is telling your browser to provide authentication for all your clicks at that site for some amount of time.

In such a system, you could wander the web very easily. Most actions on the web don't require any privilege, and so would look no different. When it came time to do something that required some authentication, you would see you were doing that and proceed.

Technology changes

This requires new software in your browser or at least an add-on. The add-on would handle authentication, of course, using digital signatures and if need be for universal auth systems, certificates. It would need to be able to show the special UI, either right in boxes and clickable links, or possibly both there and a special box in one of the browser's toolbars.

Unlike some password-entry systems, it may not be necessary to take special steps to assure no other application or web site can mimic the special UI, though it might still be a good idea. At worst, a mimic app could just make you think an action is authenticated when in fact it is not, which does little good to an attacker. On the other hand, it is essential that web site code and plug-ins not be able to cover over your authentication UI so that you perform an authentication action without realizing it, or at a higher level of identity than you realize. So this needs more study.

The browser, as modified, would identify in all HTTP requests that it supports AuthAct. This in turn would tell web sites that they can deliver forms and links that ask for authentication to perform them. Now there is no harm in the sites providing this information in otherwise invisible tags to older browsers, but the site will want to know that you don't support authenticated actions so that it can offer you older methods (such as login screens, captchas, OpenID URLs, user creation and the like.)

Web designers will have to know that privileged submit buttons and some links will need a different UI, and the buttons must be designed to have information included in them. While I like the idea of the button saying "Submit as BradT" it is also possible that it makes more sense to have the button just say "Submit (icon)" where the icon is a special one for AuthAct which tells the user to click on it or look in the toolbar or status line for details about just what authenticated action is going to take place. This needs more care as we must be sure users can't be easily tricked to authenticate in ways that violate their privacy without them thinking about it. (Fortunately, due to the way digital signatures work, it doesn't help a malicious site to get you to authenticate to it using a more privileged ID, such as the one you use with your bank. They only learn who you are, they get no powers to perform actions as you. However, they could be proxying to another site and acting as a man in the middle unless proper care is taken. All requests for authenticated action must themselves be signed by the site they are coming from.

As such a request for an authenticated action would come with tags that sign the request, and if not over SSL, which provide the certificate of the signer. They would indicate what sort of action is being performed, and what classes of identities might be used, and whether cookies will be set based on the response.

Roaming

Like password vaults and digital certificates, the AuthAct approach presents a problem for people who want to roam, both to other machines of their own, and to untrusted machines in internet cafes. Systems like OpenID will let you use your ID and password to authenticate yourself elsewhere, though they still present a risk that your OpenID password could be sniffed at an internet cafe. However, they can work on any browser -- there is no requirement for a specialized browser as AuthAct has. An AuthAct user, faced with a vanilla browser, would have to go back to today's solution of using userids and passwords. Unfortunately, she might have trouble remembering them. The AuthAct system could include the idea that with many of the identities the action also means, "And create an old style account for me with this userid and password" or the user could be prompted for such. Sites could be given an OpenID URL to create an account with.

While of course it doesn't seem particularly good to have to create an account at sites that will demand an account, today that is your only option. So this doesn't make things any worse, it just eventually makes them better.

One could also create proxy servers which are trusted with credentials when going to a computer with an old browser. You could connect to one with https though again an untrusted internet cafe computer is always a risk.

Because of the roaming issue, it could be that AuthAct would start off only being practical for lower level actions, in particular posting comments on message boards, and as a simple one-click login. This is no small feat, since these are a large fraction of the authenticated tasks one performs on the web in a given day. Most users, forced to create accounts, will use a standard account and password that is the same on all the sites. This is insecure, though not terribly so as there just isn't a lot of damage that can be done with such passwords. So this would be an improvement, though not much more of one than other solutions. As more authenticated actions become possible, the benefit would increase.

This would still be a contrast over systems like OpenID. As OpenID was envisioned, you would just have to provide your OpenID URL once to authenticate to a site, and if you had logged in recently, you would not need to log in again. The reality is that many sites are using OpenID as a way to slightly streamline the process of creating a dedicated account on the site -- which is not much benefit at all.