The Three Facets of Service Authentication for OpenID

7th Apr 2007

OpenID is working great for authenticating humans to consumer sites, but several people have been trying to employ it for use in other protocols. In my case, I drafted Post In My Weblog and Send A Message — two very simple services built on the OpenID Infrastructure. This also includes, for example, applications like Last.fm's app which reports back to the server on the music you listen to.

There are three different “modes” of operation for service authentication in OpenID:

Service-to-service (two-party): in this situation, some kind of agent is authenticating as itself to perform some action. For example, a social networking site may be authenticating to my Send A Message endpoint to deliver a notification message to me.

User-to-service (three-party): in this situation, a user (probably human) is authenticating as itself to perform some action. For example, the Last.fm client logs in as me to log what I'm listening to. I have provided it with whatever information is necessary to do so.

User-accompanied service-to-service (four-party): this is like a combination of the above. Some kind of agent is doing an action the behalf of a user (probably human), so although it is the agent that performs the action, it is the user's credentials that are used. For example, with the Post In My Weblog protocol I can give one-time permission to Flickr to post a set of photos in my weblog.

So far I have drafted OpenID HTTP Authentication for the service-to-service case and OpenID Exchange (name is very likely to change) for user-accompanied service-to-service. These both use HTTP requests as the fundamental request primitive, which means that existing HTTP-based protocols can be easily re-oriented towards OpenID Authentication.

I do not yet have an answer for user-to-service, though my gut feeling right now is to build apon service-to-service by specifying a secure method by which a client app can retrieve a signature from a user's OP for use with OpenID HTTP Authentication. However, there is a standing issue that OpenID HTTP Authentication can currently only operate in “dumb mode”, which is vulnerable to man-in-the-middle attacks. Existing non-HTTP protocols can also benefit from this, as whatever we specify for user-to-service HTTP authentication is likely to be easy adapt to a SASL mechanism.

It is my belief that making the above possible is key to unlocking OpenID's potential an identity infrastructure rather than just a signle sign-on protocol. The above three authentication modes in addition to the existing browser-based OpenID Authentication protocol provide a good basis for a variety of interesting identity-related protocols and applications built apon the basic OpenID infrastructure.